Skip to content

How it works

This page is for shop owners, managers and anyone setting up an integration without writing code. It explains what actually happens between “a customer presses Send” and “a lead appears in BytePhase”. Developers will find the same story in more detail in the Quick Start and Authentication.

How BytePhase integrations workSourcesYour website formWordPressTypeform / JotForm / Tally.soZapier / n8nIndiaMART / JustdialBytePhaseharbor-repairintegration keyvalidatemapde-duplicateone workspace, one key per sourceResultsNew Leadappears on the Leads screenSelf check-inappears under RepairsActivity logevery request, with its request idZapier keys can also READ recent repairs, customers, leads and payments — intake keys never can.
Every source sends into one workspace through its own integration key; BytePhase validates, maps and de-duplicates, then creates the lead or self check-in and logs the request.

A submission can come from many places, and they all end up on the same road:

  • Your website — a contact or “book a repair” form, either posting straight to BytePhase or through the WordPress plugin.
  • A form builder — Typeform, JotForm or Tally.so, sending each response to BytePhase as a webhook.
  • A marketplace — IndiaMART or Justdial pushing an enquiry from your listing.
  • An automation tool — Zapier or n8n, forwarding data from any of the thousands of apps they connect to.

Whatever the source, it sends a small package of fields: a name, a phone number or email, and usually a message and some device details.

When you connect a provider under Settings → Integrations in BytePhase, the app creates an integration key for it and shows it once on the Connect step (“Copy this key now. You will not be able to see it again.”). Depending on the provider you paste that key — or a Webhook URL that already contains it — into your website, plugin, form builder or automation tool.

Every submission carries that key. It is how BytePhase knows the submission is for your workspace and this integration, and it is why nobody can push records into your account without it. If the key is ever exposed, Rotate key on the integration’s Activity screen replaces it immediately.

On arrival, BytePhase:

  1. Checks the key — is it real, is it still active, and is it allowed on this endpoint? A rejected key is refused before anything else happens.
  2. Reads the fields — either BytePhase’s own field names, or your form’s names translated through the field matches you reviewed in the wizard (“Left is what your form sends. Right is where it lands in BytePhase”).
  3. Validates them — a name is required, and at least one of mobile number or email, so there is always a way to contact the person. Anything your form asked that BytePhase has no field for is kept as a custom field rather than thrown away.
  4. Checks for duplicates — according to the choice you made on the If this customer already exists… step. BytePhase matches by mobile number or email. Skip the submission keeps the existing record; Create a new record always adds one.
Lifecycle of one submissionRequestBearer bp_… · JSON body · Idempotency-KeyKey & provider checkwhich workspace · which provider typeRate limit60 requests per minute, per integrationIdempotency-Key replay checkseen this key before? answer the same way againField validation & mappingprovider field names → BytePhase fieldsinvalid fields → 422, logged as FailedDuplicate-customer policymatch by mobile or email, then reuse or createCreate Lead / Self check-inJordan Ellis · iPhone 15 Pro · Harbor Repair Co.Response{ status, request_id, data } + X-Request-IdRow on the Activity screenSuccessfulDuplicateReceivedFailedkey validwithin limitfirst time seenvalid & mappedevery outcome is logged401 unknown key403 wrong provider type429 too many requestsback off and retryReplayoriginal result returnedstatus: duplicateForm not configured yet202 received — parkeduntil you map the fields
One submission, in order: authenticate, rate-limit, replay check, validate and map, de-duplicate, create, respond, and log a row on the Activity screen.

The wizard’s first question — What should happen when someone submits this form? — decides what gets made:

  • A lead — “Someone is only enquiring. Save them to follow up later.” A lead is assigned to a staff member and sits in the Leads list with its source, status and comment.
  • A self check-in — “Someone checks in a device for repair. You can track it right away.” A self check-in carries the device, fault and any pickup or scheduling details, so the job is already in the queue when the customer walks in.

Records created this way go through exactly the same path as ones typed in at the counter, so assignment, duplicate handling and notifications behave the same.

  • In the app — the new lead appears in the Leads list, or the self check-in in Self Check-ins, straight away, for the staff member it was assigned to.
  • On the integration’s Activity screen — every submission is listed with when it arrived, what it created, and a status: Successful, Duplicate, Received (logged, but waiting for the form to be activated or its fields matched) or Failed (something was missing — the entry says what). Failed and Received entries can be retried once the cause is fixed, so nothing a customer sent is lost.

If a lead seems to be missing, the Activity screen is the first place to look.

Nothing goes live until you press Activate on the wizard’s last step. Before that, submit your form once as a test: the submission is captured, its fields are detected, and you can check where each one lands. Afterwards, Send test on the Activity screen sends a sample through the whole path and tells you what happened.