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)

1. Approval endpoints
2. Webhooks
3. Templates
4. Admin UI (optional)
5. 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