Day 0
Prove access
Create the key, complete one authenticated request, and save the first response with its metadata.
Open step →API workflow guide
What do you want to build?
Choose the outcome closest to your job. Each path gives you one working request, what the response should contain, how to check it worked, and the next useful step.
Five practical paths
Start with the outcome, not the endpoint list.
Selected: Troubleshoot a request
Path 1
Fetch macro data
Retrieve a clean time series and keep the source and quality metadata beside it.
Path 2
Plan release jobs
Use the release calendar to run targeted jobs around known publication times.
Path 3
Measure surprises
Join pre-release forecasts to the published value without introducing lookahead bias.
Path 4
Receive live updates
Use SSE as an invalidation signal, then fetch the complete record from REST.
Path 5
Build a macro model
Turn a small group of related indicators into a source-labelled currency scorecard.
Your 14-day API trial
Move from first request to a job worth keeping.
The goal is not to visit every product page. It is to complete useful authenticated API work, return on another day, and leave with a repeatable dataset or application workflow.
Days 1-2
Make the request dependable
Resolve authentication or filter problems and turn the first script into a named repeatable job.
Open step →Days 3-4
Add release timing
Use the calendar as a second endpoint family and schedule the next useful API run.
Open step →Days 5-7
Build the research output
Add expectations or a small group of macro series, then produce one saved comparison, table, or scorecard.
Open step →Days 8-10
Automate updates
Choose scheduled REST, SSE, or webhooks and complete another successful API run on a different day.
Open step →Days 11-13
Harden the client
Add timeouts, bounded retries, response validation, credential-safe logging, and stale-data monitoring.
Open step →Day 14
Review evidence
Confirm the API supplies a repeatable job your team will keep, then choose the next dataset or application workflow.
Open step →Request help
Diagnose a failed or empty response
Inspect the status and a short error body, then follow the matching fix. Never paste an API key or a full authenticated URL into a support message.
Working example
Keep your key in FXMD_API_KEY; never paste it into source control.
import os
import requests
key = os.getenv("FXMD_API_KEY", "").strip()
if not key:
raise RuntimeError("FXMD_API_KEY is not set")
response = requests.get(
"https://api.fxmacrodata.com/v1/announcements/eur/inflation",
params={"api_key": key, "limit": 1},
timeout=20,
)
print(response.status_code, response.text[:300])Expected result: A 200 confirms the key and path work. A 401 or 403 points to authentication or access, a 404 to the path, and a 429 to request pacing.
When the first script becomes a real system
Troubleshooting and production guidance
Use these guides when a response fails, returns no data, or needs production controls such as caching, timeouts, retries, and event delivery.
| Guide | Use it when | Start |
|---|---|---|
| Diagnose a failed or empty response | Separate authentication, access, path, rate-limit, and data-availability problems without exposing your key. | Open guide → |
| Make an API client production-ready | Add timeouts, bounded retries, caching, conditional requests, and the right delivery pattern. | Open guide → |