Inbound: lead ingest
The most-used integration point in the suite. A form on your own site, a landing page, another system — anything that produces an enquiry — posts to the ingest endpoint and the lead appears in CRM.
POST <ingest endpoint, exactly as issued>
Content-Type: application/json
{
"source": "website-contact-form",
"email": "[email protected]",
"name": "Rachel Nkemdirim",
"company": "Meridian Group",
"message": "Can you send pricing for 20 seats?"
}The module is mounted at /crm, so appending /crm to the ingest URL feels like the right correction. It is not: the resulting path does not exist, the post fails on your side, and the symptom is leads that never arrive with nothing obviously broken anywhere. This is the single most common integration mistake in the product.
The source is what routes a lead to the right workspace. Missing or unrecognised, the lead is created in a fallback workspace rather than rejected — so it exists and nobody sees it. Watch the fallback workspace: anything in it tells you which integration is misconfigured.
Inbound: activity
A second endpoint records an activity against a contact — a call, a conversation, an event elsewhere. It is what Phony uses after a captured conversation, and it is idempotent on the identifier you send, so a retry cannot double-record.
Where an activity references a recording or a document, the convention is to pass a URL rather than the bytes. It keeps the request small, keeps the storage in one place, and avoids duplicating something that has an access model of its own.
Outbound
There is no general outbound event system. Modules do not, as a rule, call your endpoint when something changes. The exception is the internal billing callback between the payment rail and the shell, which is not a customer-facing integration point.
The practical consequence: an integration that needs to react to a change in erp.io has to poll. If your integration depends on knowing within seconds that an invoice was paid or a task was completed, say so before building — that is a gap rather than a configuration problem.
What this does not do
You cannot subscribe to events across the suite.
There is nothing outbound to verify.
If your post fails, retrying is your side's job.
Endpoints are issued, not self-serve.
There is no delivery history to inspect for outbound events.
Questions
Can we get notified when an invoice is paid?
Not by webhook. Polling is the available approach.
Is the ingest endpoint rate limited?
Yes. See Rate limits.
Can one form feed two workspaces?
Send two posts with different source identifiers.
Related
People and organisations in erp.io CRM, how leads are routed into the right workspace, and the two ingest mistakes that make a lead vanish.
Phony peopleWhat happens after a Phony agent qualifies somebody: the person record, the hand-off to CRM, and the two reasons a lead appears to vanish.