IDs and references

You address every resource by an id you already own, so you almost never need to store a Noticia id.

Your external_id

Bring your own identifier for each resource: the customer id from your CRM, the ticket id from your POS, the store code from your back office. Send it as external_id and Noticia upserts on it, so the same id always maps to the same resource and writes are idempotent.

Noticia ids

Noticia also assigns each resource a canonical id, prefixed by type and returned in every response:

Resource	Prefix	Example
Profile	prof_	prof_cl9z3k1xb0000v8x9d2a1b3c4
Subscription	sub_	sub_cl9z3k1xb0000v8x9d2a1b3c4
Store	store_	store_cl9z3k1xb0000v8x9d2a1b3c4
Sales event	evt_	evt_cl9z3k1xb0000v8x9d2a1b3c4

The prefixes are reserved: your external_id can never start with one, so a prefixed id is always unmistakably a Noticia id.

Referencing a resource

To point at a resource, put its id in the matching <resource>Id field, profile_id, store_id or sales_event_id. It accepts either your external_id or the Noticia id:

• GET /v1/profiles/crm-customer-4815
• GET /v1/profiles/prof_cl9z3k1xb0000v8x9d2a1b3c4

And it is the same field wherever you reference a resource, in a path, a query, or a body:

• Path: GET /v1/profiles/{profile_id}
• Query: GET /v1/sales-events?store_id=paris-rivoli-01
• Body: { "store_id": "paris-rivoli-01", "profile_id": "crm-customer-4815" }

Most integrations only ever pass their own external_id. The prof_ form is there for the rare case of addressing a resource you created without one.

external_id vs <resource>Id

They carry the same value but play different roles, which is why one rejects a prefixed id and the other accepts it:

• external_id declares your id when you create a resource (POST /v1/profiles). It is yours, so it can never be a Noticia prof_ id.
• <resource>Id references an existing resource. It takes your external_id or the Noticia id, whichever you have at hand.