Skip to main content

Sync Lifecycle

Use this when you need to confirm there is no polling, and to understand how a vendor number gets back to B1Link during onboarding. There is a second webhook (for supplier updates, not onboarding) described at the bottom of this page.

What happens​

  1. B1Link: When onboarding reaches the sync point, B1Link creates an ERP event and POSTs the payload to your webhook URL.
  2. Your webhook: Receives the JSON. You read onboardingRequestErpEventId and the supplier data.
  3. Your ERP: You create or update the vendor and assign a vendor number.
  4. Your code: Returns the vendor number to B1Link using one of the two mechanisms below.
  5. B1Link: Updates the event; onboarding completes.

There is no polling: B1Link never asks your system for status. You tell B1Link when the vendor number is ready, using whichever of the two mechanisms below is enabled for you.

Returning the vendor number​

There are two ways to get a vendor number back to B1Link. Which one you use is a per-webhook B1Link configuration setting, not something you choose per request.

Option A: Asynchronous callback (default)​

This is the default for every client and needs no special configuration.

  • Your code PUTs to /api/onboarding-request-erp-events/assign-erp-vendor-number-event with body { "Id": "<onboardingRequestErpEventId>", "ErpVendorNumber": "<value>" } and header X-B1LINK-Signature.
  • B1Link returns 204 and updates the event.
  • There is no deadline: you can call this endpoint whenever the vendor number is ready, even if that's well after the webhook was received (queued vendor creation, an approval step, anything that takes longer than the webhook's own timeout).
  • See API endpoint specification for the full request/response detail.

Option B: Synchronous / inline response​

This is off by default. It's enabled per webhook by B1Link configuration. Ask your B1Link administrator to turn it on if you want to use it.

  • Instead of a separate callback, your webhook receiver returns the vendor number in the same HTTP response it sends back for the onboarding webhook, as:

    { "erpVendorNumber": "V-EXAMPLE-001" }

  • This has one critical trap. If inline mode is enabled for your webhook and your response is a 2xx status without a valid erpVendorNumber string in the body, B1Link treats that delivery as a failure (not as "vendor number not ready yet") and retries the whole webhook delivery. A 2xx with an empty or missing erpVendorNumber is the most common way clients break this mode. If your vendor number isn't ready within the request, don't enable inline mode for that webhook: use the asynchronous callback instead.

  • If you have several inline-enabled webhooks configured for the same event, the first one to return a valid vendor number wins; any later ones are skipped.

Choosing between them​

  • Use inline if your ERP can create the vendor and return a number synchronously, within the webhook request.
  • Use the asynchronous callback if vendor creation is queued, needs manual approval, or can take longer than the webhook's 30-second per-attempt timeout. This is why the callback has no deadline and inline does not: inline is bounded by the request itself, the callback is not.

Second webhook: supplier updates​

Onboarding is not the only webhook B1Link sends. Approved changes to an already-onboarded supplier are delivered on a separate webhook, with a different trigger, a different payload shape (a categories object, not a data array), and no callback step at all: only the HTTP status of your response is used. See Supplier Updates for the full payload, correlation model, and retry behaviour.

Next steps​