Getting Started

Why Physical Access is Different

Understanding why DoorFlow requires stricter security than typical APIs

4 mins
Beginner

If you're used to integrating with consumer APIs, DoorFlow's security requirements might seem strict. Here's why physical access control needs a different approach.

What's at Stake

Consumer APIs

•
Read user data
•
Post content
•
Send notifications
•
Process payments

Physical Access APIs

•
Unlock building doors
•
Grant access to secure areas
•
Control who enters facilities
•
Manage credentials that work 24/7

The difference: Physical access directly impacts real-world safety and security. A compromised API key doesn't just leak data - it could let unauthorized people into buildings.

No Fraud Checks or Chargebacks

This is the most critical difference from financial APIs:

Financial API (like Stripe)

•
Transaction flagged as suspicious → Blocked automatically
•
Fraud detected later → Chargeback reverses it
•
Multiple layers of protection
•
Money can be returned

Physical Access API (like DoorFlow)

•
Door unlocked → Person enters immediately
•
No fraud detection can stop physical entry
•
Cannot reverse someone walking into a building
•
Once they're inside, it's too late

Example scenario:

Compromised API credentials unlock a door at 2am. Someone enters the building and:

  • Accesses confidential files
  • Steals equipment
  • Compromises security systems
  • Leaves before anyone knows

You cannot

•
Reverse the entry
•
Get a chargeback
•
Detect fraud before entry happens
•
Undo physical access retroactively

This is why OAuth is required. Unlike financial transactions that can be reversed, physical access is permanent and immediate.

Why OAuth Instead of API Keys

With API keys, DoorFlow would have no way to know

•
Who authorized your app to control their doors
•
Which account owns the buildings you're accessing
•
What permissions the account owner agreed to
•
When consent was given or revoked

With OAuth

•
Each customer authorizes your app themselves
•
They see exactly what permissions you're requesting
•
They can revoke access anytime from their dashboard
•
Full audit trail: "Visitor App granted access at 9am"
•
Your app never sees their credentials

Common Questions

Why can't I just use API keys for testing?

A: You'd build your entire integration around API keys, then have to completely rewrite it for OAuth in production. OAuth testing is straightforward - and we have guides to help.

This seems like overkill for my simple use case.

A: Physical access control has no "simple" use cases. Even unlocking one door involves legal liability, insurance requirements, and audit obligations. The OAuth overhead is minimal compared to these risks.

Can't you just trust established developers?

A: Physical security operates on "Zero Trust" principles. Even trusted partners could have security breaches, rogue employees, or bugs that expose credentials. It's not personal - it's how physical security works.

The Bottom Line

You're not just building an app - you're building part of a physical security system.

The OAuth overhead is minimal. The security benefits are essential.

Next Steps

Never used OAuth before?

  • [What is OAuth and Why Use It?] - Start here

Want to understand more?

  • [Physical Access Security Deep Dive] - Compliance, granular permissions, industry standards
  • [Understanding Security Requirements] - What you need to implement

Ready to build?

  • [Your First API Request] - Working example
  • [OAuth Authorization Flow] - Visual guide
  • [Quickstart Guide] - Complete implementation

On this page