# Creating a project in your ERP

## Creating a project in your ERP
Projects are created inside Mercura (from a GAEB file, from an email
intake, or by a user), so — unlike tenders — there is no partner path
that creates one. What you get instead is a **handoff you can react
to**: a Mercura user opens the project and clicks **Send to ERP**, and
Mercura emits a `project.exported` webhook.
The round trip:
1. **You subscribe** to `project.exported` (Settings → Integrations →
For developers → Webhooks). The button only appears in Mercura for organisations that
have an active subscription for this event — no subscription, no
button, so nothing can be handed to an endpoint that is not listening.
2. **A user clicks the button.** Mercura emits `project.exported`
carrying `project_id`, `name`, the current `object_number`, the
lifecycle `status` and `request_count`. Nothing on the project is
changed by the click: its lifecycle `status` stays as it was, and
`object_number` remains yours to assign.
3. **You fetch** `GET /projects/{project_id}` for the full record —
addresses, custom fields, `request_ids`.
4. **You create** the object in your ERP and **acknowledge** it with
`POST /projects/{project_id}/acknowledgements`, sending your document
number as `external_id`. That number lands on the project's
`object_number` and comes back to you as `erp_object_id` on every
later tender/order export for the project.

Re-clicking the button is safe and always emits again — the payload then
carries the `object_number` you acknowledged earlier, which is how you
tell an update from a create without keeping your own mapping. The
acknowledgement of the previous handoff stays visible to the Mercura user
next to the button, so a `FAILED` acknowledgement with a `message` is the
way to tell them what went wrong on your side.

Version: 1.79.2

## Description:

  - `Creating a project in your ERP` ()
    Projects are created inside Mercura (from a GAEB file, from an email
intake, or by a user), so — unlike tenders — there is no partner path
that creates one. What you get instead is a **handoff you can react
to**: a Mercura user opens the project and clicks **Send to ERP**, and
Mercura emits a `project.exported` webhook. The round trip: 1. **You subscribe** to `project.exported` (Settings → Integrations →
For developers → Webhooks). The button only appears in Mercura for organisations that
have an active subscription for this event — no subscription, no
button, so nothing can be handed to an endpoint that is not listening.
2. **A user clicks the button.** Mercura emits `project.exported`
carrying `project_id`, `name`, the current `object_number`, the
lifecycle `status` and `request_count`. Nothing on the project is
changed by the click: its lifecycle `status` stays as it was, and
`object_number` remains yours to assign.
3. **You fetch** `GET /projects/{project_id}` for the full record —
addresses, custom fields, `request_ids`.
4. **You create** the object in your ERP and **acknowledge** it with
`POST /projects/{project_id}/acknowledgements`, sending your document
number as `external_id`. That number lands on the project's
`object_number` and comes back to you as `erp_object_id` on every
later tender/order export for the project. Re-clicking the button is safe and always emits again — the payload then
carries the `object_number` you acknowledged earlier, which is how you
tell an update from a create without keeping your own mapping. The
acknowledgement of the previous handoff stays visible to the Mercura user
next to the button, so a `FAILED` acknowledgement with a `message` is the
way to tell them what went wrong on your side.