Working with EFPRP APIs

01 / First steps

Get started with EFPRP

EFPRP APIs make environmental, wildfire, telemetry, and rural preservation data available to approved applications over HTTPS. You can begin in the sandbox without connecting to live operational systems.

The four-step path

1. Create an EFPRP developer account.
2. Define a project with an owner, purpose, environment, and required data types.
3. Create sandbox credentials and make a test request.
4. Request production access after your integration is reviewed.

Create or access your account

02 / Fundamentals

What are APIs?

An API is a documented way for one application to request data or an operation from another service. Your application sends an HTTPS request to an EFPRP endpoint; EFPRP validates the request and returns a structured JSON response.

Request anatomy

Available API families

• Wildfire risk and vegetation indicators
• Environmental and sensor telemetry
• Satellite thermal anomaly data
• Rural preservation and land-condition data
• Civil protection and alert integrations

03 / Project setup

Define your project

A project groups your application, data access, credentials, allowed origins, and usage plan. Defining it accurately helps EFPRP issue the least-privileged access your integration needs.

Project fields

04 / Catalog

Data types and freshness

The EFPRP catalog grows as new sources and services become available. New data types are added regularly, with catalog updates planned every month.

Data freshness

Each dataset declares its update interval and the timestamp of the latest source update. EFPRP refreshes the catalog at least monthly and can publish an update sooner when a more recent or higher-quality source becomes available.

Applications should display the timestamp to users and avoid assuming that every dataset updates at the same frequency.

05 / Security

Authentication

After Firebase Authentication signs a user in, the EFPRP project receives an API credential for service requests. Keep credentials on the server whenever possible; never commit them to source control.

Bearer authentication

curl https://api.efprp.org/v1/status \
  -H "Authorization: Bearer $EFPRP_API_KEY" \
  -H "Accept: application/json"

Credential rules

• Use separate sandbox and production credentials.
• Rotate keys when a team member, system, or integration boundary changes.
• Grant only the data scopes required by the project.
• Revoke credentials immediately if they are exposed.

06 / Integration

Make your first request

Start with the status endpoint, then query a read-only data endpoint using the smallest useful parameter set.

const response = await fetch(
  'https://api.efprp.org/v1/wildfire/risk-index?region=mediterranean-east',
  {
    headers: {
      Authorization: `Bearer ${apiKey}`,
      Accept: 'application/json'
    }
  }
);

const data = await response.json();

07 / Browser access

CORS and browser applications

Cross-Origin Resource Sharing (CORS) controls whether browser JavaScript from one origin may read a response from another origin. EFPRP supports preflighted requests for approved project origins.

Configure your origins

1. Add the exact scheme, host, and port to your project, for example https://app.example.org.
2. Use a separate origin for local development, such as http://localhost:5173.
3. Do not use a wildcard origin for production credentials.
4. Send an OPTIONS preflight when your browser request uses authorization headers or non-simple methods.

08 / Usage

Limits and affordable pricing

EFPRP uses project-level quotas so the platform remains predictable for public agencies, researchers, nonprofits, and growing teams. Plans are designed to keep entry costs affordable while matching higher-volume usage to operational needs.

How limits work

Exact quotas and pricing depend on the project plan and data services selected. The response headers expose current rate-limit information when available, including X-RateLimit-Limit, X-RateLimit-Remaining, and Retry-After.

09 / Reliability

Errors and retries

function retryDelay(attempt) {
  return Math.min(30000, 500 * (2 ** attempt));
}

10 / Release

Move to production

1. Confirm that the project purpose, origins, scopes, and contacts are current.
2. Run the full integration in sandbox with representative non-sensitive data.
3. Verify timeouts, retries, pagination, CORS, and credential rotation.
4. Request production approval from EFPRP.
5. Store production credentials in a managed secret store.
6. Monitor response status, latency, usage, and data timestamps after release.

11 / For teams

For business users

EFPRP projects can support public agencies, academic research, nonprofit programs, and commercial products. Select only the services needed for your use case, then choose a plan based on expected volume and freshness requirements.

What to prepare

• A short description of the intended service and audience.
• The data types and regions required.
• Expected request volume and update frequency.
• A technical contact for credentials and an operational contact for incidents.

For access, abuse reporting, or rights questions, use the contacts in the footer of this page.

Use a backend proxy in production so EFPRP credentials never reach the browser. The browser requests your server, your server authenticates with EFPRP, and your server returns only the fields the page needs.

Implementation sequence

1. Register the website origin and create a server-side credential.
2. Build a backend route such as /api/fire-risk.
3. Call EFPRP from the backend and normalize the JSON response.
4. Display the observation and its updated_at timestamp.
5. Cache stable responses and show a stale-data state when refresh fails.

Android and iOS clients should call your backend rather than carrying a permanent EFPRP key. This protects credentials and gives you one place to manage permissions, retries, caching, and push notifications.

Mobile checklist

• Return small, purpose-built payloads to the mobile client.
• Handle poor connectivity, timeouts, expired sessions, and stale timestamps.
• Never place API keys in an APK, IPA, mobile log, or crash report.
• Trigger push notifications after a server-side threshold check.

Release flow

1. Test sandbox behavior on both platforms.
2. Verify background refresh respects battery and privacy rules.
3. Test notification delivery and a human escalation route.
4. Promote the backend integration to production after review.

Use EFPRP data as the decision input and Twilio as the delivery layer. Your service should decide who receives an alert, at what severity, and how often.

Reliable alert flow

1. Poll current EFPRP data in a server-side worker.
2. Compare the observation with a documented threshold and geographic boundary.
3. Deduplicate events using a stable event ID and expiry window.
4. Write the alert to an audit store before sending it.
5. Send SMS, voice, or WhatsApp through Twilio and record the response.
6. Escalate or close the alert when a later observation changes its state.