OkaySend

OkaySend collects documents from clients through a checklist delivered as a secure portal, then chases them until every item is in. Agents send onboarding requests the moment a deal closes, hold them as drafts for review, track progress, and manage the client records behind them.

11 actions API key available

OkaySend website Platform Documentation Capability data verified 2026-08-13

An application clears initial review and the client has to supply supporting documents

Agent reads the client's details and the product type off the application record

List Templates reports which checklists the account actually has, so the flow builds one that exists

Create Document Request in Draft mode assembles the checklist and emails nobody

Get Document Request reads back every question the client will be asked

Agent posts the item list to the processor next to the file it belongs to

The processor confirms the checklist matches this client's circumstances, and only then is the request published or sent

What This Integration Enables

Almost every document connector pushes paper outward: draft it, send it, get it signed. OkaySend runs the other direction. You build a checklist once, send it to a client as a secure portal, and OkaySend chases them until every item on it is in. For anyone whose real bottleneck is not producing documents but collecting them, that inversion is the whole product.

FlowRunner agents create the request from a template the moment a deal or an application reaches the right stage, hold it as a draft for review, publish it as a link so it can be delivered over your own channel, read back every question with the answers and files the client has supplied, and keep the client list in step with the system of record. This connector defines no triggers, because OkaySend's webhook subscriptions can only be created by hand in its own dashboard and there is no API to register one, so flows poll Find Document Requests, which filters by status and sent date and is enough to pick up what has changed. That polling shape suits the work: document collection is measured in days, not in seconds, and what an operations team actually needs is a reliable answer to "what is still outstanding, and for how long."

The judgment calls here are not about chasing. They are about what a client's uploaded documents are worth and when they may be destroyed, which is why FlowRunner's human-in-the-loop design puts the scanning and reporting on the agent and keeps the destructive decision with a person.

Without FlowRunner

Chasing is a person's job Someone emails for the missing payslip, waits, and emails again

Checklists drift per file Each processor asks for a slightly different set, so files arrive incomplete in different ways

Status lives in an inbox Knowing what is outstanding means reading a thread rather than reading a record

With FlowRunner

Chasing is the platform's job The portal holds the checklist and keeps asking until every item is in

Checklists come from templates The request is built from a named template and reviewed before it reaches the client

Status is queryable Outstanding requests are found by status and sent date, and reported against the file

Use Case Scenarios

Onboarding that starts itself and asks the right things

An application reaches the stage where supporting documents are needed, tracked in Salesforce. The agent calls Find Clients to see whether this person already exists in OkaySend and Create Client if they do not, noting that creating a client contacts nobody. It calls List Templates to pick a real checklist by name, then Create Document Request in Draft mode, which sends nothing. A processor reviews the item list, and the request is then either emailed straight to the client or published as a link the team delivers through the portal the client already uses. Send To Client also requires a due date and a reminder schedule, so the chase is configured at creation rather than improvised later.
A daily report on what is genuinely stuck

Each morning the agent calls Find Document Requests filtered to incomplete with a sent date older than a chosen threshold, then Get Document Request on each one to read which specific items are still missing. That distinction is what makes the report useful: "seven files incomplete" is noise, and "four files waiting on the same proof of income document that our email template describes badly" is a process finding. The summary posts into Slack grouped by the missing item rather than by the client, and the outliers get flagged to a person.
Closing a file without destroying its contents

When the work a request belongs to is finished, the agent calls Update Document Request to move it to the archive status, which takes it out of the working list while everything the client uploaded stays where it is. The uploaded documents are then copied into SharePoint under the client's file, so the business holds its own copy independently of the platform. Deletion is treated as a separate decision with its own approval, for the reason described below.

Human-in-Loop Highlight

Delete Document Request is the operation that earns a gate here, and it is worth being precise about why, because there is a safer option sitting right next to it. Update Document Request can set a request to the archive status, which removes it from the working list and keeps everything intact. Delete Document Request does something different: it permanently removes the request and every file the client uploaded to it. OkaySend has no recycle bin. Delete Client behaves the same way on the client record.

That matters because the files a client uploaded to a request are often the only copy the business holds of a payslip, an identity document or a bank statement, and the retention rules that say when they may be destroyed are legal rules, not workflow rules. An agent running a cleanup sweep can identify candidates perfectly well: completed requests past their retention window, clients with no active file, duplicates created by a bad import. What it cannot do is know that this particular file is the one a regulator asked about last month.

So the sweep reports and waits. It posts: "12 requests are past the 7 year retention marker and eligible for deletion. Between them they hold 41 uploaded files, of which 9 have no matching copy in SharePoint. Archive all 12, delete only the 3 with a complete external copy, or hold everything?" A person decides, and the agent executes exactly what they chose. The scan, the cross check against the document store and the report were the agent's work. Deciding which client records stop existing was not.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

11 actions

Requests

Get Document Request Reads one request in full, including every question on the checklist and the answers and files the client has supplied so far. This is what turns "incomplete" into a list of specific missing items.
Find Document Requests Searches requests by title, status, sender, client, folder or the date they were sent. Since this connector has no triggers, this is the operation a scheduled sweep polls to find what has changed.
Create Document Request Creates a request from a template. The mode decides who hears about it: Draft sends nothing, Publish Link returns a URL for you to deliver yourself, and Send To Client emails the client immediately and requires a client, a due date and a reminder schedule before it will go.
Update Document Request Changes a request that has already been sent, touching only what is supplied. Its statuses are Incomplete, Complete and Archive, which makes this the safe way to retire a finished file without destroying anything.
Delete Document Request Permanently removes a request and everything the client uploaded to it. There is no undo and no recycle bin, which is why this operation sits behind the human gate on this page.
List Templates Lists the request templates on the account, both the ones OkaySend ships and the ones you have built. Read this so a flow names a checklist that exists rather than hard coding one.

Clients

Get Client Reads one client record.
Find Clients Searches clients by name, company, email or phone number. Used to resolve an existing client before creating a duplicate.
Create Client Adds a client. Creating one contacts nobody; only sending a request does that, which makes this safe to run at the front of an intake flow.
Update Client Changes a client's details, touching only the fields supplied. The operation that keeps the client list in step with the system of record.
Delete Client Permanently removes a client record. There is no undo, so this belongs in the same reviewed path as request deletion.

Frequently Asked Questions

What can FlowRunner do with OkaySend?

FlowRunner agents can run Get Document Request, Find Document Requests, and Create Document Request in OkaySend, plus 8 more actions.

Does connecting OkaySend to FlowRunner require OAuth?

No. OkaySend connects to FlowRunner with an API key, no OAuth flow required.

Can OkaySend trigger a FlowRunner workflow automatically?

OkaySend doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with OkaySend

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us