Hey everyone — over the last few months, I’ve been building SignumFlow, an API-first system for uploading documents and running programmatic workflows.
I built this because most workflow/e-signature platforms are UI-first. They require you to send users to their hosted UI and work inside their UX expectations — which is great for non-technical teams, but restrictive if you want everything embedded directly into your product.
I wanted something closer to Stripe-style developer ergonomics, but for docs + approval routing.
So I built SignumFlow.
What It Does Today
Right now SignumFlow supports:
- Uploading documents
- Starting workflows (sequential + parallel routing)
- Retrieving workflow + document state
- Developer portal → get API keys, view usage, see quickstarts
No UI is required, just call the API, handle responses, and keep your users inside your app.
Docs + quickstart:
👉 https://docs.signumflow.com
What’s Still in Progress
These are actively being built:
- Approval actions (minimal endpoint first)
- Webhooks
My goal is that approvals and lifecycle events can be driven either:
- manually (approve/reject via API), or
- automated rules (coming later)
Webhooks will complement polling so apps can react immediately to workflow transitions.
Why I’m Building This
Every product I’ve worked on that needs approvals/docs ends up reinventing the same pieces:
- Upload + store documents
- Route them through multiple people
- Track state + timestamps
- Log actions
- Notify systems
- Handle versions
- Generate/PDF-ify
- Keep users from bouncing between two platforms
Eventually, the internal tool grows into a workflow engine.
But building + maintaining that layer is painful and especially around lifecycle state, routing, concurrency, and auditing.
So the idea with SignumFlow is:
Let devs own the UI + business logic, and outsource the workflow mechanics to an API.
Basic Example
# Upload a document
curl -X POST https://api.signumflow.com/api/v1/upload \
-H "Authorization: $API_KEY" \
-F "file=@contract.pdf"
# Initialize a workflow
curl -X POST https://api.signumflow.com/api/v1/workflow/init \
-H "Authorization: $API_KEY" \
-d '{
"documentId": "doc_123",
"steps": [
{ "assignee": "alice@example.com" },
{ "assignee": "bob@example.com" }
]
}'
# Check workflow state
curl https://api.signumflow.com/api/v1/workflow/workflow_123 \
-H "Authorization: $API_KEY"
Architecture (high-level)
- Runtime: Node.js (TypeScript)
- Storage: S3
- DB: PostgreSQL
- API: REST (JSON)
- Workflow Engine: stateless + async routing
- Auth: API key per apps -
- Deployment: AWS Lambda + API Gateway (Serverless)
- Pattern: REST + polling today; webhooks soon
- Developer Portal: app + key management
Workflows are modeled as step graphs (seq/parallel).
State transitions are recorded + queryable.
Who Might Use This?
- SaaS products that need embedded approvals
- Internal tooling teams
- Platforms needing customer workflows
- Construction, insurance, real estate, healthcare, legal
- Anything requiring document routing through multiple hands
This is not meant to replace full UI-heavy signature platforms.
It’s for developers who want control and flexibility.
What I’m Looking For
If you try the API or skim the docs, I’d love feedback on:
- What’s confusing / unclear?
- Missing must-have API surface?
- Naming improvements?
- A feature you expect but don’t see?
- Does the value proposition make sense?
Even one small insight would be super helpful this early.
Docs:
👉 https://docs.signumflow.com
Roadmap (Short term)
- Approval endpoints
- Webhooks
- Templates
- Admin UI (optional)
- SDKs (TS + Python)
If you’ve built workflow engines, approval systems, or signature integrations before, your feedback would mean a lot.
Thanks for reading!
Happy to answer any questions.
—
Junior
Founder, SignumFlow
Top comments (0)