The systems a proposal already touches, connected on purpose.
A CRM that owns the account, storage that holds the deal file, a directory that decides who works here, and a REST API and webhooks for everything else — with an explicit answer, per connection, to the question of which system is authoritative.
- Surfaces
- CRM, storage, identity, calendar, chat
- For everything else
- REST API and signed webhooks
- States
- Which system wins on each field
Two systems that both think they own the account.
Nobody adopts a pursuit tool in isolation. There is already a CRM with the account in it, a document store where the deal file lives, and a directory that decides who has access to anything. The question is never whether to connect them; it is what happens when two of them disagree.
Most integrations answer that question by not answering it. A field syncs both ways, both sides edit it, and the last writer wins — which is fine until an opportunity owner is overwritten by an automation on a Sunday and nobody can reconstruct what happened.
The other half of the problem is failure. Endpoints go down, tokens expire, and a webhook that was delivered into a 500 is a business event that silently did not happen. An integration without a delivery log is an integration you find out about when somebody asks why the CRM is empty.
- Records that disagreeTwo systems, two owners for the same opportunity, and no rule about which one is right.
- Events lost in a 500A notification that failed once and was never retried is a decision nobody downstream ever heard about.
- Access that outlives employmentA tool provisioned by hand keeps a leaver’s account alive until somebody remembers it exists.
From a connection to an event that arrived, or is being retried.
Every integration is configured the same way: what moves, in which direction, and who wins when both sides changed.
Connect the system
Credentials are held per organization, encrypted, and scoped to the smallest permission the connection needs.
A connection owned by your organization rather than by whoever set it up.
Declare direction and authority
Each field is outbound, inbound or two-way, and every two-way field names the system that wins on conflict.
A written answer to the question every sync eventually asks.
Emit events on real boundaries
An opportunity matched, a decision recorded, a section approved, an export produced — states worth reacting to, not every keystroke.
A small, stable event vocabulary rather than a firehose that has to be filtered downstream.
Deliver, retry, and give up visibly
Deliveries are signed, retried with exponential backoff, and paused after the retry budget with the failure kept.
A delivery log with the response body, and the ability to replay once the far end is fixed.
Reach everything else over the API
The REST API exposes the objects the interface reads, scoped to the organization the key belongs to.
A way to build the integration nobody wrote a connector for.
A morning of deliveries, including the one that failed.
Five events on one endpoint: three delivered, one on its third retry with the next attempt scheduled, and one paused after the retry budget because the endpoint returned gone. Beside them, the payload of a matched opportunity and the table of which system is authoritative for what.
One endpoint, one morning, including the delivery that failed
- opportunity.matcheddelivery: delivered
- decision.recordeddelivery: delivered
- response_project.section_approveddelivery: retrying
- export.produceddelivery: delivered
- opportunity.closing_soondelivery: failed
Every delivery is stored with its response, and a failed endpoint is paused rather than retried forever. Deliveries can be replayed once the far end is fixed, which is the difference between an event system and a notification.
Reading the same data over the API
curl https://api.rfp.co/v1/opportunities \
-H "Authorization: Bearer $RFP_API_KEY" \
-G --data-urlencode "profile=prof_bridge_inspection" \
--data-urlencode "min_score=70" \
--data-urlencode "closes_after=2026-09-01"The API is the same one the interface is built on, scoped to an organization by the key it was called with. There is no endpoint that reads across tenants.
{
"id": "evt_01J9Q7M4KX8ZT2",
"type": "opportunity.matched",
"created": "2026-08-18T11:04:12Z",
"organization": "org_7Q2M",
"data": {
"opportunity": {
"id": "opp_5163T",
"source": "state_portal",
"closes_at": "2026-09-08T19:00:00Z",
"score": 74,
"profile": "prof_bridge_inspection"
},
"reasons": [
{ "factor": "capability_overlap", "awarded": 28, "available": 35 },
{ "factor": "past_performance", "awarded": 22, "available": 25 }
]
}
}- CRM
A qualified opportunity becomes an opportunity record; the account and owner come back.
The CRM owns the account and the owner. RFP.co owns the score, the requirements and the decision.
- Document storage
The solicitation package and every export are written to the deal folder.
Write-only, into a path you configure. Nothing in storage is read back as truth.
- Identity provider
Single sign-on, and group membership mapped to roles.
The directory owns who works here. Removing somebody there removes their access here.
- Calendar and chat
Question deadlines and submission times as events; state changes as messages.
Notification only. Nothing in a calendar or a channel changes a record.
Event names and payload shape are from this fixture. The failing delivery is the point of the panel: an integration that hides its failures is an integration you debug in production.
Nothing above is a live query or another customer’s pipeline. Every record in it was written for this page, and no buying organization named in it is real.
What an integration surface has to provide.
Categories rather than a wall of logos. A named connector list on a marketing page is a claim that is true per tenant and older than the page it is printed on.
CRM, with an authority rule
A qualified opportunity becomes a record in the pipeline your sales team already works, and the CRM keeps ownership of the account while RFP.co keeps the score and the decision.
Document storage, write-only
Packages and exports are written into the deal folder where the rest of the file lives. Nothing in storage is read back as truth.
Identity and provisioning
Single sign-on with roles mapped from directory groups, so removing somebody in the directory removes their access here.
Calendar and chat
Question deadlines and submission times as calendar events, state changes as messages — notification only, never a path that changes a record.
Signed, replayable webhooks
Every delivery is signed and logged with its response, retried with backoff, paused rather than retried forever, and replayable afterwards.
A REST API over the same objects
Opportunities, signals, predictions, projects, requirements and exports — the objects the interface reads, with rate limits stated per plan.
Three integrations worth building.
What teams connect first, and what they get for it.
A firm whose CRM is the system of record
- Sales manage everything in the CRM and will not adopt a second place to look for pipeline.
- Qualified opportunities pushed as CRM records, with the account and owner read back and the CRM authoritative for both.
- Pursuit work happens where the proposal is written, and the pipeline stays where the sales team already looks.
An organization with a security team
- Every application has to authenticate through the directory, and access reviews are quarterly.
- Single sign-on with role mapping from groups, and the append-only audit trail exported for review.
- Access is granted and removed where the rest of it is, and the review has a record to read.
A team with its own tooling
- Runs a warehouse and an internal dashboard, and wants pursuit data alongside everything else.
- The API for scheduled reads, and webhooks for the state changes that should not wait for a nightly job.
- Pursuit data lands in the internal reporting without anybody exporting a spreadsheet each month.
API access and webhooks start at Professional.
Email alerting is on every plan. The programmable surface — API keys, webhooks and chat delivery — arrives with Professional, and the call allowance and rate limit rise from there. Private and custom source connectors are an Agency capability.
- Every plan includes email alerting.
- Professional and above include API access, webhooks and chat notification.
- Monthly API calls and the per-minute rate limit rise with each plan.
- Agency adds private and custom source connectors, for a credentialed system of your own.
Plan names and allowances are mirrored from the billing catalog. Amounts are on the pricing page, which reads them from Stripe rather than from a number typed into a marketing page.
What people ask about integrations.
Which specific tools do you connect to?
What is stated here is the category — CRM, document storage, identity, calendar and chat — because a named connector list is true per connector and per tenant, and goes out of date faster than a marketing page does. Anything without a first-party connector is reachable through the REST API, which covers the same objects the interface reads.
Which system wins when both have changed?
Whichever one the connection says wins, and every two-way field has to name one. The CRM owns the account and the owner; RFP.co owns the score, the requirements and the decision. Storage is written to and never read back as truth.
What happens when our endpoint is down?
The delivery is retried with exponential backoff up to the retry budget, then paused with the failure and the response kept. Once the endpoint is fixed, deliveries can be replayed — which is the difference between an event system and a notification.
Is the API the same one the product uses?
It covers the same objects the interface reads, scoped to the organization the key belongs to. There is no endpoint that reads across tenants, and authorization is checked on the server for every call.
Can we bring our own source?
Private and custom source connectors are an Agency-plan capability — a credentialed portal or an internal feed, with the credentials held by your organization and used only by your listeners.
Connect one system and watch the ledger.
Point a webhook at an endpoint you control, run a pursuit through qualification, and read the deliveries — including what happens when you take the endpoint down on purpose.