I Built an API-First Document Workflow Engine (Looking for Feedback)

Junior Charles — Tue, 11 Nov 2025 15:07:52 +0000

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

DEV Community: Junior Charles