The endpoint accepts anything that reaches it
An unauthenticated URL sitting in a form's configuration. Anyone who learns it can post to it, and nothing on the receiving side can tell a real submission from an invented one.
FormAssembly · API & Custom Development
There is no connector for the system that matters most to you.
It was built in-house, or bought in 2009, or belongs to a regulator. FormAssembly reaches it through an authenticated webhook and a REST API available on every plan. Twopir Consulting designs the payload, the authentication and — where delivery has to be guaranteed rather than attempted — the middleware that sits between them. Supported surfaces first. Custom code only where nothing else reaches.
12+
500+
40+
250+
Trusted by 500+ organizations — including healthcare, higher education, nonprofit and financial services teams whose most important system has no connector.
Built for Regulated Data Collection
- Salesforce Partner
- HubSpot Partner
- Webhook Connector
- REST API
- OAuth & API Keys
- Custom JSON Payloads
- Middleware & Retry
- Legacy Systems
Six ways a custom integration becomes a liability
Custom code is not the problem. Custom code nobody scoped, documented or monitored is the problem, and it is usually written under time pressure by someone who has since moved on. Each of these is a decision that was never made, not a mistake that was made.
Delivery is assumed rather than confirmed
The request is sent and nobody checks whether it arrived. When the receiving system is down for an afternoon, those submissions are simply gone from its point of view.
The whole submission is sent everywhere
The fastest payload to build is all of it. That is also how regulated data reaches a system whose controls were never scoped to hold it, with no record of the decision.
Nobody can say what it was supposed to do
Code with no documentation of intent. The next person can read what it does but not why, so nobody will change it — and eventually a workaround is built around it instead.
There is no reconciliation record
You cannot answer how many submissions reached the target system last quarter, or which ones did not. In a regulated process that is not just an operational gap, it is an evidence gap.
Code was written where configuration would have done
A custom script solving something a connector, a formula or a dynamic picklist already handles. It works, and it is now a permanent maintenance obligation that did not need to exist.
What This Covers
Two supported surfaces, and the judgement about when to use them
FormAssembly exposes two programmable surfaces. The webhook connector posts a payload you define — JSON, raw or URL-encoded — to any endpoint when a form is submitted, with OAuth or API-key authentication, custom headers, conditional dispatch, and defined behaviour when the request fails. The REST API, available on all plans, lets you work programmatically with forms, themes, connectors and responses, which is how large estates get provisioned, audited and exported without anyone clicking through the admin interface. Between them they reach almost any system. This page covers designing against both, and building middleware where guaranteed delivery or reconciliation is required.
Where this page stops. If a native connector already exists, use it — the Salesforce connector at depth is FormAssembly Salesforce integration, and sequencing several supported connectors across one submission is FormAssembly integration services. Custom JavaScript inside the form itself belongs to FormAssembly customization services. Approval routing across several forms is FormAssembly workflow automation. This page is for what is left after all of those.
What Twopir does, and what the product does. The webhook connector, its payload builder, its authentication options and the REST API are FormAssembly capabilities. What we contribute is the design and the code around them: what the payload contains and what it deliberately omits, how the credential is scoped, whether delivery needs a queue, and what evidence the process has to produce. We also say when a requirement does not need code at all, which is more often than most custom-integration conversations assume. Product documentation is the FormAssembly Resource Center.
Six kinds of custom work, in order of how often they are needed
Most requirements stop at the first two. The rest exist for cases where delivery, evidence or scale make a direct webhook insufficient.
Webhook Payload Design
The most common answer, and usually the right one. A defined payload to a defined endpoint, carrying exactly what the target should receive.
- JSON, raw or URL-encoded bodies built to the target's contract
- Custom headers for routing, versioning and tracing
- Conditional dispatch so requests are sent only when warranted
- Deliberate omission of fields the target should not hold
- Several destinations reached from one submission
Authentication & Secrets
An authenticated endpoint is the difference between an integration and an open door. Scoped so the credential can do only what the integration needs.
- OAuth or API-key authentication on every request
- Secrets held in platform configuration, never in a form
- Least-privilege scoping of the credential
- Rotation planned rather than discovered during an incident
- Transport and payload reviewed against your security standard
Middleware & Guaranteed Delivery
For when a failed request must be retried rather than logged, and when the target needs the data in a shape the form cannot produce.
- Transformation into the target's required structure
- Queueing and retry with backoff on transient failure
- Enrichment from a third system before delivery
- Dead-letter handling so nothing is silently dropped
- Alerting that reaches a person, not just a log
Reconciliation & Evidence
A record of what was sent, when, and what came back — which regulated processes require and almost no direct webhook provides.
- Per-submission delivery status across every destination
- A reportable answer to what reached the target last quarter
- Replay of a specific failed delivery after a fix
- Retention aligned to the process's evidence obligations
- Audit-ready export for a reviewer who is not technical
REST API Automation
For estates large enough that the admin interface stops scaling. Available on all plans, and under-used almost everywhere.
- Provisioning forms and themes from a template
- Scheduled response export into a warehouse
- Configuration audit across a whole estate
- Bulk administrative changes without manual clicking
- Process reporting: abandonment, cycle time, record quality
Salesforce-Side Development
When the right place to solve it is the CRM rather than the form. As a Salesforce Partner we can build on that side too.
- Apex and Flow to process what a submission creates
- Data model changes that make the mapping simpler
- Platform events for downstream orchestration
- Matching logic beyond what connector lookups reach
- One team accountable across both sides of the boundary
Direct webhook, middleware, or no code at all
Every additional layer is a permanent maintenance obligation, so each one has to be earned. We place a requirement on this table before quoting it.
| What the requirement needs | Right answer | Why not the heavier option |
|---|---|---|
| A native connector already exists | Use the connector. No custom work at all. | Custom code here is a maintenance obligation you were not required to take on. |
| Send data to an internal system, best effort acceptable | Direct authenticated webhook. | Middleware adds infrastructure for a guarantee the process does not need. |
| The target needs a different data shape | Middleware to transform, unless connector logic can do it. | Contorting the form to match a target's schema makes the form harder to change. |
| Delivery must be guaranteed, not attempted | Middleware with a queue, retry and dead-letter handling. | A webhook's failure handling logs the problem; it does not resend on your behalf. |
| The process must produce evidence of delivery | Middleware with a reconciliation record. | Connector logs show attempts, but are not an evidence trail a reviewer can use. |
| Bulk admin, provisioning or scheduled export | REST API, available on all plans. | Doing it by hand does not scale, and a webhook is the wrong surface for it. |
Prove configuration cannot do it, then write the least code that can
Durations describe typical engagements for one integration. Middleware adds to stage three rather than to the whole timeline.
Rule Out Configuration
We check the requirement against connectors, formulas and dynamic picklists first, and say so plainly when custom work is not needed. Two to five days.
Contract & Security Design
The payload contract with the target's owner, what it deliberately omits, the authentication model and the credential's scope. Agreed in writing. Three to five days.
Build & Instrument
Webhook configuration, and middleware where stage one justified it — built with logging and reconciliation from the start rather than added after an incident. One to four weeks.
Failure & Load Testing
Target unavailable, credential rejected, malformed response, duplicate delivery and slow response all exercised deliberately against a test endpoint. Three to five days.
Handover & Ownership
Readable code, documented intent rather than just mechanics, a runbook for the tested failures, and a note of what needs retesting when either side changes. One week.
The build-versus-buy question, answered by someone who could have built it
The engagement below is Twopir's own, on the adjacent problem of getting inbound capture into Salesforce automatically. Beside it, a team with no shortage of engineering capacity explaining why they did not build the collection layer themselves.
US Enterprise — Legal, Financial & Insurance Services
Integrating a capture channel with Salesforce so every qualifying enquiry becomes a record automatically, with its source attached and reported back to revenue.
100% Call attribution to campaign source
Auto Lead creation on every qualifying enquiry
Closed Loop reporting back to revenue
FormAssembly Customer Story
FormAssembly is a very high-utility tool for us because it’s plug-and-play. It would take us a significant amount of dev effort to build internally in Amazon, and we’d also spend a good amount of bandwidth maintaining that tool.
Abhinav Singh Kakran Manager of Program Management, Amazon India — quoted in FormAssembly’s published case study, not a Twopir engagement
We will talk you out of code when configuration would do
We help growing and mid-market companies solve complex CRM, integration and business system challenges, and we work with enterprise organizations on the same problems at larger scale.
Stage one is ruling ourselves out
We check connectors, formulas and picklists before proposing code. A custom integration that did not need to exist is the most expensive thing on this page.
We design the payload for least privilege
What the target receives is a decision, not a default. Sending everything is faster to build and is how data reaches systems that were never scoped to hold it.
We instrument from the start
Logging and reconciliation designed in, not bolted on after the first incident — which is when they are hardest to add and most urgently wanted.
We own both sides of the boundary
As a Salesforce Partner and HubSpot Partner we can build in the CRM as well as against the form, so the work goes where it actually belongs.
We hand over code you can actually maintain
Written to be read, documented with intent rather than mechanics, and delivered with a note of what to retest when either end changes.
What technical teams ask before committing to custom work
It posts a payload you define to any endpoint when a form is submitted. You control the body — JSON, raw or URL-encoded — through a builder rather than a fixed template, and you can add custom headers, authenticate with OAuth or an API key, apply conditional logic so the request is only sent in certain circumstances, and define what happens when the request fails. Several destinations can be reached from a single submission. For most homegrown and legacy systems that is enough on its own, with no middleware required.
Three situations. When the target system needs the data in a shape the form cannot produce — a different structure, a lookup against a third system, a computed value that connector logic cannot reach. When delivery has to be guaranteed rather than attempted, so a failed request needs queuing and retry rather than a log entry. And when you need a reconciliation record proving what was sent, when, and what came back — which regulated processes usually require. If none of those apply, a direct webhook is the simpler and more maintainable answer.
Administration and data movement rather than form submission. It is available on all plans and lets you interact programmatically with forms, themes, connectors, responses and other components of the account. In practice it is used for bulk work the interface makes slow: provisioning forms from a template, exporting responses into a warehouse on a schedule, auditing configuration across a large estate, and reporting on the process rather than just the submissions. It is the right tool once an estate is large enough that clicking through the admin UI stops scaling.
Authentication on every request, using OAuth or an API key rather than an unauthenticated endpoint that anyone who learns the URL can post to. Secrets held in the platform's configuration rather than embedded in a form. Least-privilege scoping so the credential can do only what the integration needs. Transport over TLS. And a decision about what the payload is allowed to contain, because the quickest way to create a compliance problem is to send an entire submission to a system whose controls were never scoped to hold it.
Sometimes, and we will tell you when the answer is no. Where a system has a file-based or database interface, middleware can bridge to it. Where the only route in is a human typing into a screen, the honest answer is that automating it is a bigger project than this page describes, and the better question is usually whether that system should remain the destination. We would rather say that during scoping than build something fragile around it.
You own it, and we make sure that is a realistic proposition rather than a formality. Custom integrations are written to be read, documented with the reasoning rather than just the mechanics, and handed over with a runbook covering the failure cases we tested. We also flag what needs retesting when either side changes, since a custom integration is exposed to updates at both ends. Retained support is available where the surface keeps growing, but it should be a choice rather than something the design forces on you.
Next Step
Tell us the system, and what the process owes
What it is, what it accepts, and whether the process has to prove delivery or merely attempt it. Those three answers usually decide between a direct webhook, middleware, and no code at all — and we will tell you which before there is an engagement to protect.
Or contact the team — supported surfaces first, custom code last
