How to Connect n8n to BytePhase (Automation Setup Guide)
Send data from any n8n workflow into BytePhase and turn it into a Lead or a Self Check-in — no dedicated BytePhase node required. n8n talks to BytePhase through its built-in HTTP Request node, POSTing a small JSON envelope to a single BytePhase endpoint with an API key in the header. This guide covers generating that key, building the request body, and a worked example workflow you can copy: a Webhook trigger, a Set node to rename fields, and an HTTP Request node to send them on. It takes about 10 minutes if you already have a workflow that receives form or event data.
What You’ll Need
| Requirement | Notes |
|---|---|
| A BytePhase account with access to Business Settings | Needed to open Settings → Integrations |
| A running n8n instance | Self-hosted or n8n Cloud both work identically — this is a plain HTTP call either way |
| About 10 minutes | Longer if you’re building the source-data workflow from scratch |
What the n8n Integration Does
BytePhase has no n8n-specific backend code — n8n is wired in the same way any custom REST caller is, by POSTing a canonical JSON envelope to BytePhase’s /integrations/submit endpoint. The envelope has three parts: a form_id you choose (any string, useful for filtering in the Activity log), a destination (lead or self_checkin), and a data object with the canonical field names from the mapping reference below. Pick lead for enquiries your team follows up, and self_checkin for device drop-offs a customer reports themselves — matched by mobile number, and converted into a repair job with one click once the device is actually in your hands. BytePhase never creates a job or ticket automatically from either destination.
How the n8n Integration Works
Someone submits your form
A customer fills in the n8n form you already use — nothing changes for them.
Your workflow posts to BytePhase
An HTTP Request node sends the submission to one authenticated BytePhase endpoint, using your API key.
Your field map is applied
Each answer is matched to a BytePhase field. Anything you did not map is kept as a custom field.
The record is created
It lands as a Lead or a Self Check-in — whichever destination that form is set to — and is written to the Activity log.
Step 1: Open the n8n Card in BytePhase
Log into BytePhase and go to Settings → Integrations. Under Website & Forms you’ll find an n8n card. Click Connect to start the setup wizard.
Step 2: Choose Where Submissions Land
The wizard opens on Destination, and it comes first because everything after it depends on the answer — the field map you review later belongs to the destination you pick here. Choose Self Check-in if the workflow should open a job for a device that is coming in, or Lead if it should raise an enquiry for your team to follow up. Your workflow then sends the matching value in the destination field of the JSON body. You are not choosing once and for all — see running both side by side below.
Step 3: Copy Your Endpoint URL and API Key
The wizard’s Connect step gives you two things: the submit endpoint —
https://<tenant>.api.bytephase.com/api/<tenant-slug>/integrations/submit
— and an API key, shown once, that you send as an X-API-Key header rather than in the URL. Copy both now; if you lose the key you’ll need to rotate it and update your workflow.
Step 4: Build the HTTP Request Node
In your n8n workflow, add an HTTP Request node (n8n’s own reference for this node: n8n HTTP Request node documentation) and configure it:
- Method: POST
- URL: the endpoint from Step 3
- Headers:
X-API-Key: YOUR_KEY,Content-Type: application/json - Body: JSON, matching the envelope shape below
Example request body, sending a repair enquiry as a Lead:
{
"form_id": "n8n-website-contact-form",
"destination": "lead",
"data": {
"name": "Jordan Lee",
"email": "jordan@example.com",
"mobile_number": "+14155550101",
"device_type": "Laptop",
"device_brand": "Dell",
"comment": "Cracked screen, need a quote"
}
}
Store the API key in n8n’s credentials manager rather than typing it directly into the node — that keeps it out of any exported workflow JSON.
Step 5: Send a Test Submission and Map Your Fields
Execute the workflow once (or trigger it manually with test data) so BytePhase receives a real request. Back in the wizard, click Check now — it also polls automatically every few seconds. Because you control the field names in the data object, the source keys BytePhase detects are whatever you sent; if you already used the canonical names from the mapping table, the wizard’s auto-match should line most of them up immediately. Confirm at least one of email or mobile is mapped, then continue. Anything you don’t map is preserved as a custom field rather than dropped.
Step 6: Set the Duplicate Policy and Activate
Choose how repeat submissions are handled. The defaults are sensible starting points — Lead defaults to skip a repeat submission (matched by email OR mobile + country code); Self Check-in defaults to create a new record even for a returning customer (matched by mobile against any check-in still open). Review the summary screen and click Activate integration. Nothing goes live until you do.
Run Self Check-in and Lead Side by Side
You do not have to pick one for the whole account. A single integration can serve several forms at once, and each one carries its own destination and its own field map. BytePhase keys every entry by form and destination together, and the destination pinned in the URL is absolute — a Self Check-in URL will never fall through to a Lead entry or borrow its field mapping.
So one workflow can open a Self Check-in while another raises a Lead, from the same n8n instance, running in parallel. Add the second form in the wizard, choose the other destination, and give it its own URL. The Activity log records which destination each submission was routed to, so the two never blur together.
A Worked Example Workflow
A simple, reliable pattern for pulling in submissions from any source:
- Webhook node — receives the raw payload from your form, chatbot, spreadsheet automation, or whatever’s upstream
- Set node — renames the incoming fields to BytePhase’s canonical names (e.g. rename
full_nametoname,phonetomobile_number) and assembles theform_id/destination/datashape - HTTP Request node — POSTs the assembled body to
/integrations/submitwith theX-API-Keyheader from Step 3
Retry safety: n8n’s built-in retry-on-fail can resend the same request if a node times out. Add an Idempotency-Key header to the HTTP Request node with a value unique to that submission (a form response ID works well) — BytePhase deduplicates on it, so a retried request never creates a second Lead or Self Check-in. Without it, BytePhase falls back to a payload-hash check for the same day, which is a reasonable safety net but a real idempotency key is more precise.
Field Mapping Reference
Lead and Self Check-in are two different record types, so they accept two different sets of fields. Map as many as your n8n form collects — anything left over is kept as a custom field, not discarded. Pick the table that matches the destination you chose in Step 2.
Lead fields
Use this table when the destination is Lead — an enquiry to follow up, before any device is handed over.
| BytePhase Field | Required? | Notes |
|---|---|---|
name | Yes | Max 60 characters |
email | One of email or mobile | Max 255 characters |
mobile_number | One of email or mobile | Max 20 characters |
mobile_country_code | No | Max 10 characters; paired with mobile_number for duplicate matching |
phone_number | No | Secondary phone number, max 20 characters |
contact_person_name | No | Max 60 characters — for enquiries raised on behalf of a business |
source | No | Max 100 characters; matched to an existing lead source by name |
role_id | No | One of 7, 8 or 9; defaults to End User when omitted |
next_follow_up | No | Date — schedules the first follow-up |
comment | No | Free text |
device_type | No | Max 100 characters; matched to an existing device type by name |
device_brand | No | Max 100 characters; an unmatched value is kept as a custom brand name |
device_model | No | Max 100 characters; an unmatched value is kept as a custom model name |
address.address_line | No | Max 200 characters |
address.city | No | Max 100 characters |
address.state | No | Max 100 characters |
address.zip_code | No | Max 20 characters |
Duplicate handling: Leads default to Skip. BytePhase looks for an existing lead with the same mobile_number and mobile_country_code, or the same email, and reuses it instead of creating a second one.
Self Check-in fields
Use this table when the destination is Self Check-in — a customer handing in a device, so the record carries serial numbers, accessories and pickup details a Lead has no place for.
| BytePhase Field | Required? | Notes |
|---|---|---|
name | Yes | Max 255 characters |
email | One of email or mobile | Max 255 characters |
mobile_number | One of email or mobile | Max 20 characters |
mobile_country_code | No | Max 10 characters |
device_type | No | Max 255 characters; matched to an existing device type by name |
device_brand | No | Max 255 characters; an unmatched value is kept as a custom brand name |
device_model | No | Max 255 characters; an unmatched value is kept as a custom model name |
serial_number | No | Max 255 characters |
serial_number_2 | No | Max 191 characters — a second serial or IMEI |
device_password | No | Max 191 characters — unlock code or device password |
accessories | No | A list, or a comma-separated string — split into individual items |
comment | No | Free text — the reported fault |
is_recovery | No | Boolean — flags the job as a data-recovery case |
is_pickup_booked | No | Boolean — marks that a pickup was requested |
scheduled_on | No | Date — the requested pickup or drop-off date |
custom_fields | No | Object; each value max 1,000 characters |
address.address_line | No | Max 255 characters |
address.city | No | Max 255 characters |
address.state | No | Max 255 characters |
address.zip_code | No | Max 20 characters |
Duplicate handling: Self Check-ins default to Create, so every submission becomes its own check-in — the right behaviour when the same customer brings in a second device. Only if you change the policy to Skip does BytePhase look for a match, and it then matches on mobile_number against open check-ins only.
Testing & Monitoring Your Submissions
Every request — successful, duplicate, failed, or simply received — shows up on the integration’s Activity screen, with both the raw JSON your workflow sent and the mapped version BytePhase saved. Use Send test to fire a synthetic submission without running your live workflow, and the one-click Retry action to replay anything that failed once you’ve fixed the cause. Three failures in a row trigger a warning banner in the app; five in a row also email your tenant’s support address. Submission logs are kept for 90 days. Note that BytePhase processes each request synchronously and returns the result immediately — there’s no queue in between, so your HTTP Request node’s response reflects the real outcome right away.
Troubleshooting
| Symptom | Likely Cause | Fix |
|---|---|---|
| 401 Unauthorized | X-API-Key header missing or wrong, or the key was rotated in BytePhase | Re-copy the key from Settings → Integrations → n8n and update the HTTP Request node’s header |
| 422 Unprocessable Entity | The data object is missing both email and mobile, or destination isn’t lead/self_checkin | Check the Set node’s output against the field mapping reference before it reaches the HTTP Request node |
status: duplicate in the Activity log | The submission matched an existing Lead or open Self Check-in under your duplicate policy | Expected behavior — adjust the duplicate policy (skip/create) if it’s catching more than you want |
| Request succeeds but fields land in custom_fields instead of mapping | Your JSON keys don’t match BytePhase’s canonical names (e.g. phone instead of mobile_number) | Rename fields in the Set node to match the mapping reference, or remap them in the wizard’s Match Fields step |
| A retried workflow run creates a duplicate Lead | n8n’s retry-on-fail resent the same request without an idempotency key | Add an Idempotency-Key header (see the worked example above) so retries are deduplicated instead of creating new records |
| 429 Too Many Requests | The workflow is looping or firing faster than 60 requests per minute | Add a rate-limit or wait step before the HTTP Request node, or batch submissions |
Security
Your API key is sha256-hashed at rest — BytePhase can verify it but can’t display it again, so store it in n8n’s credentials manager as soon as you copy it. Rotate it any time from the integration card; the old one stops working immediately. Because n8n sends it as a header rather than embedding it in a URL, it’s less likely to end up in logs by accident — but it will still appear in an exported workflow JSON if you paste it directly into the node instead of using a credential. Submissions are isolated per tenant — this endpoint only ever writes into your own BytePhase account.
Start Automating Lead Capture With n8n and BytePhase
Once your workflow is live, anything it touches — a form, a spreadsheet row, a chatbot conversation — can become a Lead or Self Check-in in BytePhase without anyone re-typing it. From a Self Check-in, converting to a repair ticket is one click once the device is actually in front of you. If you’d rather connect a form directly without building a workflow, see the Typeform and Jotform setup guides, or the Zapier guide for a no-code automation route. See every connector BytePhase supports on the integrations page.
BytePhase includes the n8n integration on every plan, with a 15-day free trial and no credit card required. Start your free BytePhase trial →










