Skip to content
Sign in

Masnet is used on a computer. You can create your account from your phone and sign in from your desktop.

Developers

Bring Masnet events into Salesforce

Masnet does not call Salesforce directly. An intermediary receives the signed event, verifies it and writes to Salesforce. There are two routes; choose according to the model of your organization.

On this page

Requirements in Masnet

Before configuring the receiving system, prepare the destination in Masnet. The steps are the same for every system.

  1. Open Company › Integrations (the Spanish interface labels it Empresa › Integraciones), go to the Destinations tab and select New destination. If the integration has no authorized data yet, Masnet asks you to authorize it first.
  2. In Destination address (https) enter the receiver public URL. It must be https, port 443 or 8443 and a public DNS name: user information in the URL, fragments, IP addresses and internal names are not accepted. A query string is allowed; Masnet treats the whole URL as a credential.
  3. In Format choose Standard JSON (application/json) or Structured CloudEvents (application/cloudevents+json). The event content is the same; see Webhooks.
  4. Select Create destination. Masnet shows the signing secret (whsec_…) only once. Store it immediately in the receiver secret store; it cannot be read again.
  5. Select Test destination and then Send test. The integration is activated only after a successful test; then use Activate destination.

Possible routes

Routes
RouteHow it worksWhen it fits
MuleSoftA Mule application receives the event following the MuleSoft guide and updates Salesforce objects with its connector.MuleSoft already exists and transformations are needed.
Platform EventsThe intermediary (MuleSoft, a function of your own or another) publishes a Platform Event in Salesforce through its REST API, and Salesforce flows or triggers consume it.You want to decouple receiving from the internal logic of Salesforce.

In both, the address registered in Masnet is that of the intermediary, not of Salesforce.

Signature verification

The signature is v1, followed by base64(HMAC-SHA256) computed with the binary key obtained by base64-decoding what follows whsec_, over the bytes webhook-id + . + webhook-timestamp + . + the exact body. Always verify over the received bytes, before parsing the JSON.

Verification happens in the intermediary, before calling Salesforce, following the guide for its technology: MuleSoft, Node.js, Python, Java or C#.

Define the platform event (event fields) with the data you need from data.object; for example, the Masnet identifier, the contract code and the status. The names of the platform event fields are yours: define them in Salesforce.

Response

The intermediary answers 2xx to Masnet once it has verified the signature and left the event in a queue or published it. Do not wait for processing inside Salesforce: Masnet cuts the request at 15 seconds.

Testing with the test event

  1. Activate only the intermediary receiving first, without writing to Salesforce.
  2. In Masnet, select Test destination and Send test.
  3. When the test succeeds, enable writing in a Salesforce test environment.

Operation: duplicates and ordering

  • Idempotency. webhook-id identifies the event and is kept across retries and redeliveries. Record the identifiers already processed and discard repeats with a 2xx response.
  • Ordering. Each resource (subject) carries an increasing sequence. Discard an event whose sequence is lower than or equal to the last one applied for that subject. Events of different resources have no order between them.
  • Retries. Masnet retries any non-2xx response for up to 72 hours; the full schedule is in Webhooks.
  • Secret rotation. When rotating with overlap, the previous secret stays valid for 24 hours and webhook-signature carries two v1,… signatures separated by a space. Accept the event if either one matches.

Troubleshooting

Masnet records the response code of each attempt in the delivery history. These are the effects of each receiver response:

Receiver responses and their effect
Receiver responseEffect in Masnet
2xxSuccessful delivery. It means receipt, not business processing.
3xxThe redirect is not followed. It counts as a failure and is retried; the history shows the Location without its query string.
400, 401, 403, 404 and other 4xx or 5xxRetryable failure for up to 72 hours from the start of the delivery cycle.
410Masnet disables the destination and cancels pending deliveries. Return 410 only if the destination must stop receiving events.
413The event is marked as undeliverable to that destination and is not retried.
429 or 503 with Retry-AfterRetry-After (seconds or HTTP date) is honored up to a maximum of 1 hour.
No response within 15 secondsTimeout (5 s to connect, 15 s in total). It is a retryable failure: answer 2xx and process asynchronously.