Jupiter ERP can send business events to an HTTPS address you provide. That starts work in another system without polling for changes. Setup is under System → Webhooks.
Webhooks are included in the trial and on the Enterprise plan, with up to five endpoints. Other plans do not include them. The allowance is listed under System → Subscription.
An event is sent only to endpoints that are active and subscribed to that event. All events accepts every type. The same event id can go to several endpoints. Each endpoint has its own delivery.
Add an endpoint
- Open System → Webhooks. The Endpoints tab is selected.
- Click Add webhook. Give it a name and a public HTTPS address. Jupiter ERP does not call private addresses or follow redirects.
- Choose the events this endpoint should receive, or all events.
- Copy the signing secret immediately. It is shown only when you create the endpoint and when you rotate the secret. Store your own headers on the endpoint with Add header, for example an API key. Jupiter ERP sets
Content-Type,User-Agent, andJupiter-ERP-Signatureitself.
Each delivery is a POST with JSON. The Jupiter-ERP-Signature header looks like t=1710000000,v1=…. t is the Unix timestamp. v1 is an HMAC-SHA256 of the text timestamp.body, calculated with the secret, as hex. The body is the raw request text, not a reformatted JSON document. The User-Agent header is Jupiter-ERP-Webhook/1.0. Treat the secret like a password. Compare the timestamp with the current time and reject old messages.
Answer on that same address within 10 seconds with a 2xx status. Do the real work after that. Jupiter ERP does not follow redirects.
From the endpoint menu you send a test, turn the endpoint off or on, rotate the secret, or delete the endpoint. Sending a test and rotating the secret require the update permission.
Test with webhook.ping
webhook.ping is not a business event. It starts only when you choose Send test on an active endpoint.
Jupiter ERP then stores a real event of type webhook.ping and delivers it only to that endpoint. The event selection does not matter for this. Marking webhook.ping in the list does not schedule automatic tests.
An inactive endpoint does not accept a test. Turn it on first.
The envelope is the same as for the other events. data.object is ping. data.item is only { "ok": true }. Signature, retries, and the row under Deliveries apply to the test as well.
{
"id": "evt_01J...",
"type": "webhook.ping",
"api_version": "1.0.0",
"created_at": "2026-10-10T19:00:00+00:00",
"account_uuid": "…",
"data": {
"object": "ping",
"item": { "ok": true }
}
}The id starts with evt_. If the same id arrives again, it is the same fact, not a new one.
When an event is sent
Jupiter ERP stores a business event only when at least one active endpoint is subscribed to it. Otherwise there is no row.
| Type | When |
|---|---|
webhook.ping | Only from Send test, to that endpoint alone. |
invoice.created | You create an invoice, including a draft. A service contract sends this when it creates an invoice. An invoice created from time tracking does not. |
invoice.sent | You send a finished invoice. Drafts cannot be sent. A service contract also sends this when the invoice goes out as it is created. |
invoice.cancelled | A cancellation sets the invoice to canceled. That also sends credit_note.created for the credit note. |
credit_note.created | You create a credit note, or a cancellation creates one. |
credit_note.sent | You send a credit note. |
quote.created | You create a quote. |
quote.accepted | A quote is accepted. |
quote.rejected | A quote is rejected. |
contact.created | You create a contact. |
contact.updated | You save an existing contact. |
receipt.created | You create a receipt. Later edits and text recognition do not send another event. |
document.signed | A recipient signs the document. |
document.declined | A recipient declines the signature. Expiry does not send an event. |
Message contents
Besides the fields in the test, business messages carry a short snapshot in data.item. Read the full record through the Account API (see Manage API and MCP access). The technical reference is at https://www.jupiter-erp.com/en/reference/webhooks.
Amounts are in cents. 450 is 4.50 in the given currency.
Invoices, credit notes, and quotes include id, status, number, formatted number, date, net, gross, currency, and, when set, contact, project, and cost center with a name. Receipts have no invoice number. They include receipt type, reference, issuer reference, date, amounts, and the same links. Contacts include type, name, company name, and contact number. Signatures include status plus the document type and id.
Deliveries
The Events tab lists stored events. Filter by event type and date range, and open the payload that was sent.
The Deliveries tab shows whether a message arrived. Status, endpoint, time, and the individual attempts are listed there.
A 2xx response finishes the delivery. Status 410 turns the endpoint off immediately. 429, 5xx, timeouts, and network errors are retried: after about 1 minute, 5 minutes, 30 minutes, 2 hours, 8 hours, and 12 hours. The gaps vary slightly. After the seventh attempt the delivery is failed. Other 4xx responses and redirects are not retried.
Ten failed deliveries in a row turn the endpoint off. A successful delivery resets the counter. Turn the endpoint back on once the address is reachable. You can send a failed or canceled delivery again.
If the plan changes from trial or Enterprise to a plan without webhooks, every endpoint is turned off. Open deliveries are canceled. The address, secret, and history stay. When the feature returns, the endpoints stay off until someone turns them on again.
Common questions
Who can manage webhooks?
Read, create, update, and delete are separate permissions. Sending a test and rotating the secret belong to update.
Can I manage webhooks with an API token?
Yes, through the Account API, when the token has the matching webhook permission. Setup in the panel stays under System → Webhooks. The signing secret is shown through the API only on create and rotate. Create tokens as described in Manage API and MCP access.
Why does the same event arrive more than once?
A delivery is retried when the receiver does not answer with success in time. The same event id means the same fact. Process it only once.
