Integration Engineering
Connect websites, apps, SFTP bridges and automation platforms to SupaChrome safely.
Open interactive lesson and quizWhat you will learn
- Create and govern integration sources
- Send validated custom-object records and relationships
- Operate retries, key rotation and delivery failures
A gym uses a QR attendance app while finance exports payments to SFTP. You need both systems to create reliable custom-object records without duplicate check-ins or exposed credentials.
Lesson 1
Choose the right integration path
Use the Object Records API for standard app-to-CRM record delivery, the Website Event API for clicks, leads, products and purchases, and outbound webhooks when SupaChrome must notify another system. CSV remains best for governed bulk migration. SFTP requires a secure bridge that reads a file and calls HTTPS.
Choose by the meaning of the payload. A custom Attendance record belongs in the Object Records API. A purchase attributed to a marketing campaign belongs in the Website Event API. These interfaces have different schemas, so a payload that works for one cannot simply be copied to the other. Use the endpoint and schema displayed for the selected source and object.
For a file-based system, a scheduled server or middleware process can read SFTP, validate rows and send HTTPS requests. SupaChrome does not directly browse an external FTP server. Start with one record, confirm the saved result, and only then increase the batch size.
Lesson 2
Authenticate without exposing secrets
Create one integration source per sending system. SupaChrome shows its key once and stores only a hash. Send the key as a Bearer token from a server, middleware or automation platform—never place it in public browser JavaScript. Pause a source during investigation, rotate a suspected key, and revoke it permanently when retired.
Keep integration keys in a server-side secret store or the protected credentials section of your middleware. Do not put a key in a public page, tracking URL, shared screenshot or downloadable CSV. Create separate sources for systems such as checkout and attendance so that one can be paused without stopping the other.
When rotating a key, update the sending system and verify a successful delivery before retiring obsolete configuration. A paused or revoked source should no longer accept requests. Treat an authentication failure as a configuration problem to investigate; do not respond by removing the authorization header or exposing the key in browser code.
Lesson 3
Map object fields and relationships
Every standard CRM and active custom object has a BU-scoped endpoint under /api/records/BU_CODE/OBJECT_API_NAME. GET returns its field API names. For custom objects, send displayName, fields keyed by field API name, and relationship values keyed by relationship API name. For standard CRM objects, send fields keyed by standard API name and optional customFields. Relationships resolve only inside the BU. Inspect each row result before retrying.
Read the object schema before writing the payload. Display labels are for people; API names are the stable keys used by the interface. For an Attendance object, map the occurrence time and status into the configured fields, and use a relationship to the existing member. Do not create a second member merely because a attendance event arrived.
Send a test with a valid relationship and another with an unknown reference. Verify that the invalid row is rejected rather than linked to an arbitrary customer. Keep the same source identifier for the same attendance event across retries, and inspect both the API result and the object record in the BU.
Lesson 4
Design idempotent, observable delivery
Use upsert with a stable externalId from the source. The same source, object and externalId updates one record, so network retries do not create duplicates. Send at most 100 records per request, inspect row-level results, and archive source files only after the delivery log confirms acceptance.
Treat a network timeout as an unknown outcome: the receiver might already have saved the record. A stable externalId lets an upsert identify the same source record when retried. Do not generate a fresh identifier for every attempt. Split larger deliveries into batches of at most 100 records, retaining a record of which source rows belong to each batch.
Inspect every row result even when the HTTP request succeeded. Retry transient failures with a delay and respect Retry-After responses. Correct validation errors before resubmitting them. Keep the batch identifier, accepted count and rejected rows in your sending system so you can reconcile delivery without storing secret keys in logs.
Practice · Connect a QR attendance system
- Install the Gym & fitness blueprint in a Trial org
- Create an Object Record API source and copy its one-time key
- Open Objects & fields and compare Contact and Attendance API names
- Send an upsert to the Attendance endpoint and review row-level results
- Confirm the Attendance lookup and delivery result