API
Create and send documents programmatically.
Developers
WQ3 for developers
Create documents, send them for signature and get the signed result back into your systems.
What you can build
Embedded signing
Let users sign inside your own application.
Status updates
Get notified when documents change status.
Related
WQ3 API
Use WQ3 signing from inside your own applications and systems.
Integrations
Connect WQ3 to ERP, HR, CRM, productivity and storage systems, or build a custom integration.
Get started in three steps
Get your keys
Request API keys from our team.
Try the test environment
Create a document, add signers and send it.
Receive events
Subscribe to webhooks to track every signature in real time.
Turn signing requirements into application rules
Before implementation, decide which signing level each participant needs. WQ3 has exactly three levels: electronic signature, remote signing and token signing, and different signers can use different levels within one document. Model your application rules around each signer’s requirements rather than assuming a single choice applies to everyone.
Treat eKYC account verification as a separate decision: it is an identity-verification add-on available with any level, not a fourth signing level. Electronic signatures suit everyday agreements, while remote or token signing suits formal or high-value contracts. Review your contract requirements with your legal team before turning these choices into application defaults.
Create a clear review boundary before sending
WQ3 documents are locked once sent, so your application should include a final review before signing begins. Ask users to confirm the document version, intended participants and signing level for each person. This separates content preparation from signing and helps avoid uncertainty about which version is being approved.
Design the surrounding experience around individual access: each signer has a private invitation link that shows only what belongs to them. Avoid placing signer links in shared screens or widely accessible diagnostic messages. For embedded signing, distinguish permission to manage a workflow from permission to view a signer’s documents, rather than treating access to your application as sufficient authorisation.
Test the application logic around signing events
Plan what your application should do when a status update arrives, not just how it receives the notification. Identify the internal business record associated with the signing process, what users need to see and which actions must wait for completion. A “sent” state in your interface should not imply that the agreement is complete.
Also test how your application handles delayed or interrupted processing, and how it avoids repeating an internal action if processing runs again. These are application-design considerations, not claims about WQ3 event-delivery guarantees. Before launch, confirm event payloads, authentication, retry behaviour and error handling with the team instead of inferring them from the page’s overview.
Plan for documents and evidence after completion
Design your records process to retain the final document and its supporting evidence, rather than only a completed status. Every completed WQ3 document comes with an audit trail and completion certificate, supporting internal review and record keeping. Associate these materials with the relevant business record and decide who needs access within your application.
For later checks, a public verification page is available without an account, using the contract’s QR code and reference. File-integrity comparison uses a SHA-256 fingerprint, so preserve the original final file rather than relying only on a modified copy. WQ3 is aligned with Egyptian E-Signature Law No. 15 of 2004, but legal effect depends on meeting applicable conditions, not simply using an API.
REST API
Start integrating with one request.
Create a document, add signers, and follow every event from inside your application.
POST /v1/documents
{
"name": "contract.pdf",
"signers": [
{ "email": "sara@example.com" }
]
}Start your first signing journey today.
Create your WQ3 account, or talk to us about your organization’s requirements.
Frequently asked questions
Must every signer use the same level?+
No. Different signers can use different levels within one document, so your application rules should account for each participant’s requirements.
Is eKYC a signing method?+
No. It verifies the account holder’s identity. An eKYC-verified account can be required with any of the three signing levels.
When should document review finish?+
Before sending, because documents are locked once sent. Include a final confirmation step before starting the signing workflow.
Does a recipient need an account to verify a completed contract?+
No. The public check page supports verification without an account; its QR code appears in the final file and completion certificate.
Which technical details should I confirm before implementation?+
Request authentication details, request fields, event payloads, retry policies and error-handling guidance; the current page does not specify these details.