What it does
Anything that can send a signed HTTP request can start a piece of work: your own form, an automation tool, a script, or a system with no native Briedo connection.
This is the general-purpose route. If you want your software to read back from Briedo as well as write to it, use the API instead.
What Briedo reads
Exactly what you send, within limits on size and nesting. Briedo does not fetch anything from the sender and never follows a URL the payload contains.
What Briedo may write
Nothing. This direction is inbound.
Permissions you are granting
One shared secret, which Briedo shows once when you create the connection and once again if you rotate it. Anybody holding it can create work in your workspace, so treat it as a password.
How to connect
- Go to Settings, then Integrations, then Before discovery, and add an inbound connection.
- Copy the address and the secret. The secret is shown once.
- State what this connection relays. Briedo offers two choices: "A form people fill in" or "A CRM or business system". You say what it IS; Briedo decides what that is worth.
How to route work
Every request is one submission. Include your system’s own identifier for that submission so a retry is recognised as the same one, and map the values you send onto the things Briedo wants to know. The connection screen shows a complete worked example for your workspace, with your own address in it.
How mapping works
You name the Briedo item and give it a value. Most values are plain text or numbers. Some things have parts — an address is a street, a town and a country — and where your setup expects parts you send them as parts. Sending one line of text where parts are expected is refused rather than half-accepted, and the thing stays open for somebody to answer properly.
You cannot tell Briedo how much to trust what you send. There is no field for it, and a request containing one is rejected.
How to test it
- Send the worked example from the connection screen, unchanged.
- Confirm a piece of work appears.
- Send it a second time with the SAME submission identifier, and confirm you still have one piece of work, not two.
- Then send your real payload.
How to know it is working
- Briedo answers with a success response rather than a rejection.
- One submission produces one piece of work, and a retry produces none.
- The values you mapped appear on the work, attributed to this connection.
When it goes wrong
| What you see | What it means |
|---|---|
| Rejected as unsigned or badly signed | Sign the exact bytes you send. Re-serialising the body before signing changes it. |
| Rejected as too old or too far ahead | The timestamp must be in seconds and within five minutes of Briedo’s clock. |
| Duplicate work | Your retry sent a different submission identifier. |
| Accepted, but nothing was settled | You have not said what the connection relays, or the source is not permitted to settle those particular facts. |
How to disconnect
Revoke the connection. Requests signed with its secret stop being accepted immediately, whether or not the sender has been updated.
What happens to what it already told us
Nothing is deleted. Work that was already prepared keeps everything it learned, including the record that this system is where it came from. Those are records of what was true at the time, and disconnecting a system later does not make them untrue.
What stops is new information arriving. Deleting historical data is a separate request, and a deliberate one.