Show HN: SignumFlow – API-first document routing and workflow engine
6 hours ago
Hi HN,
I’m building SignumFlow — an API-first way to upload documents and run workflows.
Most workflow + signature tools are UI-first. SignumFlow is for developers: you call the API, bring your own UI, and keep users inside your product.
Working today • Upload documents • Start workflows (sequential / parallel routing) • Retrieve workflow + document state • Approvals • Developer portal with API keys + docs
In progress • Webhooks
Docs + quickstart: https://docs.signumflow.com
If you’ve built signature or workflow integrations before: I’d love feedback on what’s confusing / missing or any must-have features.
Happy to answer questions!
Some context:
I built this because most workflow + e-sign vendors force you into their UI and signatures. My goal was to let developers embed document workflows directly into their own product — the API controls routing + lifecycle, and the developer fully owns the UX.
Architecture highlights: • API Gateway → Lambda microservices (TS/Node) • Core services: workflow, documents, auth, webhooks • S3 (per-tenant isolation) + PostgreSQL (RDS) • Async document processing via SQS + processor workers • Redis planned for caching • Observability: CloudWatch + X-Ray • Developer portal w/ key management + playground • Webhooks supported; polling fallback
Happy to talk about trade-offs (e.g., multi-tenant isolation, async processing patterns, DX decisions, Lambda vs containers) or roadmap ideas.