Formstack exposes a REST API and webhooks for everything the packaged connectors do not cover. Twopir Consulting builds on them the way integration code should be built: OAuth 2.0 credentials handled properly, webhook payloads verified, retries made safe to repeat, rate limits budgeted rather than discovered, and a failure queue that can be replayed instead of reconstructed by hand.
You need a custom integration when the packaged connector cannot express what the business actually requires — not merely when a connector does not exist. The common triggers are a destination with no connector, transformation logic the connector cannot perform, a reliability requirement stronger than the connector's own error handling, a volume pattern that needs batching, or an approval condition that has to be evaluated before the write happens.
Formstack supports this through a REST API covering forms, submissions, fields, webhooks, folders and partial submissions, with product-specific surfaces for Documents, Sign and Workflows, authenticated with OAuth 2.0. Webhooks push submission data to a URL you control at the moment of submission, and can be secured with a shared secret or an HMAC key that signs the payload so you can verify its authenticity and integrity.
Platform specifics on this page last reviewed September 2026
These are platform facts, not Twopir capabilities. They are also the facts most likely to change between releases, so verify them against Formstack's developer documentation before you design against them.
Budget the quota before you design. A daily per-token rate limit is a capacity constraint, not an edge case. A polling integration that checks every minute consumes quota whether or not anything has changed, and a webhook-driven design consumes almost none — which is frequently the deciding argument between the two patterns regardless of what the requirements document says about latency.
A webhook endpoint is a publicly reachable URL that writes to your systems. Both options are better than neither, and they defend against different things.
| Consideration | Shared Secret | HMAC Key |
|---|---|---|
| How it works | A key is sent with each request so your endpoint can confirm the caller knows it. | The payload itself is signed, so your endpoint can verify both the sender and that the content is unmodified. |
| Proves the sender | Yes | Yes |
| Proves the payload is unaltered | No | Yes |
| Exposure if intercepted | The secret travels with every request; anyone who obtains it can impersonate the sender until it is rotated. | The signing key is not transmitted, only a signature derived from it. |
| Verification cost | A string comparison — trivial, and should be constant-time. | Recompute the signature over the raw body and compare. Slightly more work, and the raw body must be preserved before parsing. |
| Our recommendation | Acceptable for low-sensitivity payloads over TLS. | The default for anything carrying personal, financial or health data. |
Verification is necessary but not sufficient. A verified webhook can still be a replay of an earlier valid request. Endpoints we build reject payloads outside a timestamp window, deduplicate on a submission identifier, and return a success response quickly while processing asynchronously — so a slow downstream system cannot cause redelivery of work that has, in fact, already been accepted.
Custom code is an asset with a maintenance cost attached. It is worth paying when it buys something the alternatives cannot, and not otherwise.
| Requirement | Start here | Go custom when |
|---|---|---|
| Field-to-field mapping into a supported app | The native connector. | The mapping needs logic the connector cannot express, or the path is critical enough to need your own error handling. |
| Real-time push to your own service | A webhook with HMAC verification. | Immediately — but the custom work is the receiving endpoint, not a replacement for the webhook. |
| Scheduled batch into a legacy system | The REST API with a scheduled job. | The transformation is substantial, or the legacy interface needs a protocol adapter. |
| Several destinations, one submission | An integration platform or middleware. | Routing depends on business logic that is easier to express and test in code than in a low-code canvas. |
| Writing into Salesforce with complex rules | The Salesforce-native package. | Logic must run inside the transaction — Apex callouts, custom validation, or orchestration that must be atomic with the record write. |
| High volume against a quota | Webhooks, which consume far less quota than polling. | You need batching, queuing and back-pressure that the packaged path does not provide. |
Endpoints built to survive the internet: verified, idempotent, fast to acknowledge and safe to redeliver.
Scheduled and on-demand integration jobs that behave predictably against a daily quota.
A transformation and routing layer when several systems need the same submission in different shapes.
Where the logic has to run inside the org, in the transaction, under governor limits.
The parts a security review will ask about, designed in rather than retrofitted.
So the team that inherits this can operate it without reading the source.
Formstack applies daily rate limiting per access token, with the specific limit depending on your plan type. Exceeding the quota returns an HTTP 429 response, and quotas reset daily. Because the exact figure is plan-dependent and changes, we verify it for your account during design rather than quoting a number. The design consequence is more important than the number: a daily quota rewards event-driven designs and punishes polling, so if your integration is currently polling on a short interval, that is usually the first thing to change.
Formstack offers two mechanisms: a Shared Secret sent with each request so you can confirm it came from Formstack, and an HMAC Key that signs the payload so you can verify both authenticity and integrity. We default to HMAC for anything carrying personal, financial or health data, because a shared secret proves who sent the request but not that the content is unaltered. Verification alone is not enough, though — a valid request can be replayed, so an endpoint should also reject payloads outside a timestamp window and deduplicate on the submission identifier.
This is the question that determines the whole design, and it should be answered before anything is built. Never assume a push delivery will be retried indefinitely — confirm the actual retry behaviour for your configuration rather than relying on a general expectation. Where the data matters, we pair the webhook with a reconciliation job that periodically queries the API for submissions in a window and fills any gaps. That combination gives you the low latency of a push model and the recoverability of a pull model, and it is the pattern we recommend for anything a business process depends on.
By making the write idempotent, which means a repeated delivery has no additional effect. In practice that is a stable key derived from the submission — its identifier — recorded at the point of processing and checked before any write, combined with an upsert against that key in the destination rather than a blind create. This matters most for ambiguous failures: a timeout does not tell you whether the first call succeeded, so without idempotency the safe-looking choice of retrying is exactly what creates the duplicate.
You do. Source, tests, deployment configuration and runbooks are handed over as deliverables, in your repository, and we walk your engineers through the failure cases we deliberately tested. You can retain us for ongoing maintenance, and many clients do, but the handover is complete whether or not you take that option. A custom integration that only its author can operate is a liability we are not willing to leave behind.
Describe the integration, its volume and how bad it would be if a submission were lost. Those three answers usually determine the pattern — and quite often the conclusion is that a configuration change gets you there without custom code at all.
Code, tests, deployment configuration and runbooks handed over in your repository. We will also tell you when custom code is avoidable work.
