{"id":130,"date":"2026-09-17T15:35:18","date_gmt":"2026-09-17T07:35:18","guid":{"rendered":"https:\/\/wp.qoraapi.com\/ai-gateway-vs-api-gateway\/"},"modified":"2026-09-20T02:49:29","modified_gmt":"2026-09-19T18:49:29","slug":"ai-gateway-vs-api-gateway","status":"publish","type":"post","link":"https:\/\/qoraapi.com\/blog\/ai-gateway-vs-api-gateway\/","title":{"rendered":"AI Gateway vs API Gateway: Key Differences and When to Use Each"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">An API gateway manages traffic to services you own: auth, routing, rate limits, WAF, observability. An AI gateway sits in front of model providers you rent and adds what an HTTP proxy cannot see \u2014 tokens, prompts, streaming deltas, and model choice. Most production stacks need both, at different layers.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">They get conflated because both are called gateways and both emit metrics, yet they answer different questions. An API gateway answers <em>is this caller allowed to reach this service, and how fast?<\/em> An AI gateway answers <em>which model serves this prompt, what did it cost, and what happens when that vendor degrades?<\/em><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What a traditional API gateway does<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">An API gateway is a north-south traffic manager for services you operate: requests arrive from outside, and the gateway decides which internal service handles them, under what conditions. Kong, NGINX\/OpenResty, Envoy, Traefik, and AWS API Gateway all converge on five jobs.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Authentication.<\/strong> Terminate TLS, validate JWTs against a JWKS endpoint, introspect OAuth2 tokens, verify mTLS certs, check API keys \u2014 so downstream services trust an identity header.<\/li>\n<li><strong>Routing.<\/strong> L7 dispatch by host, path, or header, weighted splits for canary deploys, timeouts, connection pooling, health checks.<\/li>\n<li><strong>Rate limiting.<\/strong> Token-bucket or sliding-window counters keyed on consumer, IP, or key \u2014 almost always in <em>requests per window<\/em>, the unit HTTP understands.<\/li>\n<li><strong>WAF and edge protection.<\/strong> OWASP Core Rule Set evaluation, bot mitigation, IP reputation, request-size caps, DDoS absorption before traffic reaches your fleet.<\/li>\n<li><strong>Observability.<\/strong> RED metrics per route and consumer, structured access logs, trace-context propagation into your service graph.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">The structural fact that matters: <strong>an API gateway operates on the HTTP envelope, not the payload.<\/strong> It knows status codes, byte counts, and headers. It does not know that a 200 OK consumed 4,120 prompt tokens, or that the prompt held a customer&#8217;s email. That blindness makes a generic gateway fast at the edge \u2014 and makes it unable to manage model spend.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">One consequence breaks more LLM rollouts than anything else: <strong>request-count limits are near-meaningless for LLM traffic.<\/strong> Sixty requests per minute sounds reasonable until one request is a 50-token classification and the next is a 200,000-token document analysis. Same counter, wildly different cost \u2014 and your worst-behaved tenant stays invisible until the invoice arrives.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What an AI gateway adds<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">An AI gateway is an egress-oriented proxy specialized for model APIs. It speaks the provider protocols (OpenAI-compatible chat completions, Anthropic messages, Gemini generateContent) and parses the payload. Six capabilities distinguish it.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1. Multi-provider routing and schema normalization<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">One request shape, translated to each vendor&#8217;s dialect: role naming, tool-call encoding, system-prompt placement, and error taxonomy. When one vendor returns <code>429 rate_limit_exceeded<\/code> and another returns <code>429 overloaded_error<\/code>, the gateway maps both to one internal class so your application writes one branch \u2014 which is what lets you <a href=\"https:\/\/qoraapi.com\/blog\/switch-ai-providers-unified-gateway\/\">switch AI providers<\/a> as a config change rather than a refactor.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2. Token metering and budget enforcement<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Token counts \u2014 prompt, completion, cached \u2014 are attributed per request to a key, team, feature, or tenant. That enables <em>pre-flight rejection<\/em> (estimate against budget, then downshift or refuse before spending) and <em>per-feature attribution<\/em>: the only way to know whether the summarizer or the chat assistant eats the budget.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3. Prompt-logging control<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Because the gateway parses the body, it can enforce what a generic proxy physically cannot: store nothing, metadata only, a sampled percentage, or full text with regex redaction of emails, phone numbers, and credential-shaped strings. Retention windows and per-tenant opt-outs live here \u2014 often why an AI gateway clears a security review at all.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4. Capability-aware model fallback<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Fallback does not mean retrying the same endpoint. The gateway knows which models are <em>substitutes<\/em> \u2014 same tier, comparable quality, compatible context window, ideally a different vendor and failure domain \u2014 and reroutes on 429, 5xx, or timeout. That needs a capability registry, not a retry loop; our guide to <a href=\"https:\/\/qoraapi.com\/blog\/ai-api-failover-multi-provider\/\">multi-provider failover<\/a> covers the circuit-breaker mechanics.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5. Streaming-aware proxying<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Responses arrive as Server-Sent Events, and the failure is subtle: a buffering proxy delivers nothing for twenty seconds, then dumps the whole answer. Users read that as broken. An AI gateway disables buffering on the streaming path, preserves chunk boundaries, forwards the terminal <code>[DONE]<\/code>, counts tokens from the stream, and cancels the upstream call when the client disconnects.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6. Semantic cache<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Exact-match HTTP caching is useless here, because two prompts with the same intent are almost never byte-identical. A semantic cache embeds the prompt, finds a stored prompt above a cosine-similarity threshold, and returns the prior completion. Start precision-first around <strong>0.95<\/strong> and lower it only after measuring false hits.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Three constraints keep it honest: cache only low-temperature tasks; scope entries by model, temperature, and system prompt; and never cache responses derived from permissioned data, since a hit would leak one tenant&#8217;s answer to another.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">The overlap and the gaps<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Plenty of capabilities appear in both columns, which is why teams assume one replaces the other. The gaps are what matter.<\/p>\n\n\n\n<figure class=\"wp-block-table is-style-stripes\"><table class=\"has-fixed-layout\"><thead><tr><th>Capability<\/th><th>Traditional API gateway<\/th><th>AI gateway<\/th><\/tr><\/thead><tbody><tr><td>Auth (JWT, OAuth2, mTLS, keys)<\/td><td>Yes \u2014 mature, standards-based<\/td><td>Partial \u2014 a bearer key for internal callers<\/td><\/tr><tr><td>Request-count rate limiting<\/td><td>Yes \u2014 the core strength<\/td><td>Yes<\/td><\/tr><tr><td>Token-based quota &amp; spend budget<\/td><td>No \u2014 cannot see tokens<\/td><td>Yes \u2014 per key, team, tenant<\/td><\/tr><tr><td>Routing by path \/ host \/ header \/ weight<\/td><td>Yes<\/td><td>Limited \u2014 routes by model, not by service<\/td><\/tr><tr><td>Multi-vendor schema normalization<\/td><td>No<\/td><td>Yes<\/td><\/tr><tr><td>Capability-aware model fallback<\/td><td>No \u2014 retries the same upstream<\/td><td>Yes \u2014 crosses vendor boundaries<\/td><\/tr><tr><td>Streaming (SSE) pass-through<\/td><td>Possible, but needs deliberate tuning<\/td><td>Yes \u2014 streaming-native<\/td><\/tr><tr><td>Token metering &amp; usage attribution<\/td><td>No<\/td><td>Yes<\/td><\/tr><tr><td>Prompt logging with redaction<\/td><td>No \u2014 payload is opaque<\/td><td>Yes \u2014 payload-level policy<\/td><\/tr><tr><td>Semantic caching<\/td><td>No<\/td><td>Yes<\/td><\/tr><tr><td>WAF, DDoS, bot mitigation<\/td><td>Yes \u2014 why it sits at the edge<\/td><td>Rarely<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The traditional gateway owns <em>who gets in and how much traffic they send<\/em>; the AI gateway owns <em>what that traffic costs and which model serves it<\/em>. The two &#8220;No&#8221; rows in the middle column \u2014 token budgets and cross-vendor fallback \u2014 are the entire reason AI gateways exist as a category.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Where each sits in the stack<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Direction is the cleanest way to remember the boundary. An API gateway handles <strong>inbound<\/strong> traffic to services you own. An AI gateway handles <strong>outbound<\/strong> traffic to vendors you rent from. They sit at opposite ends of the request path:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Client\n  |\n  v\n[ Edge API gateway ]      TLS, user auth, WAF, per-consumer request limits\n  |                       knows nothing about tokens or models\n  v\n[ Your application ]      business logic, prompts, tool definitions\n  |                       holds an INTERNAL token, never a vendor key\n  v\n[ AI gateway \/ egress ]   model routing, token budgets, vendor fallback,\n  |                       semantic cache, prompt-logging policy\n  v\n[ Provider A ] [ Provider B ] [ Provider C ]<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Three rules make that boundary work.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>User authentication stays at the edge.<\/strong> The AI gateway authenticates <em>your application<\/em> to the model layer with an internal credential \u2014 a credential boundary between you and your vendors, not a user-identity boundary. A leaked internal token cannot reach your services; a compromised user session cannot spend your inference budget.<\/li>\n<li><strong>Vendor keys never leave the AI gateway.<\/strong> Neither your application code nor your client devices hold a provider key. That is the largest security win of the egress layer, and it makes rotation a one-place operation.<\/li>\n<li><strong>Correlate traces across both hops.<\/strong> Propagate one trace ID from the edge into the gateway, or you will see p99 spike without knowing whether the cause was your service or a provider&#8217;s.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">A representative egress config shows how much model-specific behavior collapses into one place:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># AI gateway egress config (gateway-agnostic, illustrative)\nserver:\n  direction: egress              # outbound to providers only\n  auth: internal-token           # user auth handled at the edge gateway\n\nroutes:\n  - name: chat-completions\n    match: { path: \/v1\/chat\/completions }\n    model_tiers:                 # route by tier, not hard-coded model name\n      fast:   [gpt-mini-class, claude-haiku-class]\n      mid:    [gpt-class, claude-sonnet-class]\n      strong: [gpt-frontier-class, claude-opus-class]\n    fallback:\n      trigger: [429, 500, 502, 503, 504, timeout]\n      strategy: cross_vendor    # never retry the vendor that just failed\n      max_attempts: 3\n      total_budget_ms: 25000\n    streaming:\n      buffer: false             # SSE chunks must pass through untouched\n      cancel_upstream_on_disconnect: true\n    metering:\n      unit: tokens              # not requests\n      emit: [prompt_tokens, completion_tokens, cached_tokens, model, vendor]\n      budget: { window: 1h, on_exceed: throttle }\n    cache:\n      semantic: { enabled: true, similarity: 0.95, ttl_seconds: 3600 }\n    logging:\n      store_prompt: sampled     # none | metadata_only | sampled | full\n      sample_rate: 0.05\n      redact: [email, phone, api_key]<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Everything in that file is invisible to a generic proxy, and none of it belongs in application code.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Common mistakes<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Mistake 1: using Kong, NGINX, or an ALB for LLM routing<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">These are excellent products doing a different job. Pointed at a model API they fail four ways: request-count limits do not track token cost; SSE breaks unless you disable buffering, and the default is on; vendor error taxonomies flatten, so a 429 retries the same overloaded vendor instead of failing over; and counting tokens means parsing a body that can exceed 100 KB.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># A plain reverse proxy in front of an LLM API \u2014 three traps marked.\nlocation \/v1\/chat\/completions {\n    proxy_pass https:\/\/api.provider.example;\n    proxy_set_header Authorization \"Bearer $UPSTREAM_KEY\";\n\n    proxy_buffering off;         # TRAP 1: default is \"on\". SSE chunks are held\n                                 # until the response completes, so the UI shows\n                                 # nothing for 20s then the whole answer at once.\n    proxy_read_timeout 300s;     # TRAP 2: LLM calls exceed the 60s default.\n    limit_req zone=llm burst=5;  # TRAP 3: counts REQUESTS, not tokens. A tenant\n                                 # sending 200k-token prompts costs 1000x another\n                                 # and looks identical in this counter.\n}<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">You can close these gaps with custom plugins \u2014 but you are then maintaining a model-routing layer inside a web server, with no capability registry, no token accounting, and no semantic cache.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Mistake 2: using an AI gateway as your only auth layer<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">AI gateways ship pragmatic auth \u2014 usually a bearer key per caller \u2014 because their job is to identify a <em>budget<\/em>, not a <em>user<\/em>. That is a different question from &#8220;may this person read invoice 4471?&#8221; They have no WAF, no bot mitigation, no OAuth2 scope model, and no tenant RBAC over your resources. Exposing one directly to browsers puts a token-billing endpoint on the public internet with no edge protection.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Mistake 3: no per-request cost attribution<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">If token usage lives only on provider dashboards, you have N dashboards and no way to answer &#8220;which feature got expensive last Tuesday.&#8221; Meter at the gateway, where request, caller, and token count are in scope together.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Mistake 4: treating fallback as retry<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Retrying an overloaded vendor on 429 amplifies the outage \u2014 you have added load to a service that just told you it is saturated. Real failover crosses vendor boundaries, which means the routing layer must know which models are interchangeable. That is a data problem, not a retry-policy problem.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Decision criteria: when to use which<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Skip &#8220;it depends&#8221; and test your situation against three rules. If you expose public HTTP APIs to services you own, you need a traditional gateway for TLS, WAF, and per-consumer quotas. If you run two or more model providers, enforce a spend budget in real time, or hold prompt data under compliance review, you need an AI gateway. If you do both, you need both \u2014 the edge protects your services, the egress layer protects spend and uptime.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Then watch for these triggers, which mean you have outgrown a hand-rolled proxy:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Provider-specific request or response shaping appears in more than one service.<\/li>\n<li>Changing a model or provider requires a deploy instead of a config edit.<\/li>\n<li>Multiple keys or teams, and no single query answers &#8220;who spent what.&#8221;<\/li>\n<li>Retry and backoff logic is duplicated across services and the copies disagree.<\/li>\n<li>A prompt-logging policy must satisfy an auditor, not just a developer.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">The rule of thumb: <strong>the moment provider-specific code appears in a second service, extract the egress layer.<\/strong> Below that threshold a thin adapter is fine. Above it, you pay a maintenance tax on every model change. Our <a href=\"https:\/\/qoraapi.com\/blog\/ai-api-gateway-guide\/\">AI API gateway<\/a> guide walks through the full feature set.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">One key, many models: what a hosted AI gateway gives you<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The architecture above is correct but not free to operate \u2014 someone must run the egress tier, keep the model registry current, and track every vendor release. For most teams under roughly ten engineers, a hosted relay is the better trade. <a href=\"https:\/\/qoraapi.com\/\" target=\"_blank\" rel=\"noopener\">qoraapi.com<\/a> exposes many models from multiple vendors behind one OpenAI-compatible endpoint and one key, collapsing the egress column of the comparison table into a single integration.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Vendor keys never touch your codebase.<\/strong> Your app holds one relay credential; provider credentials live behind the gateway, so rotation stops being a multi-service event.<\/li>\n<li><strong>Model routing becomes a string.<\/strong> Move a workload between tiers by changing the <code>model<\/code> field \u2014 no adapter code, no per-vendor SDK.<\/li>\n<li><strong>Cross-vendor fallback without building a health checker.<\/strong> When a provider degrades, the relay can serve from an equivalent model instead of returning a 429 to your user.<\/li>\n<li><strong>One usage view instead of N dashboards.<\/strong> Token consumption across every model lands in one place \u2014 the prerequisite for per-feature cost work, covered in our <a href=\"https:\/\/qoraapi.com\/blog\/reduce-ai-api-costs\/\">AI API cost reduction guide<\/a>.<\/li>\n<li><strong>Streaming that behaves.<\/strong> OpenAI-compatible SSE pass-through, so existing client code works unchanged.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Note what a relay is <em>not<\/em>: it is not your edge. Keep the traditional gateway in front for user auth and WAF, keep the relay as your egress tier, and the boundary holds exactly as drawn \u2014 each layer owning what it was built for.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Frequently asked questions<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Can I just use Kong or NGINX as my AI gateway?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">For pure proxying, yes. For LLM-specific behavior you will end up writing plugins. You get no token metering and no capability-aware failover across vendors, and SSE breaks unless you disable buffering \u2014 which is on by default.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Do I need an AI gateway if I only use one provider?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Not for routing. You still benefit from token metering, keeping the vendor key out of your application, and controlling what prompt data gets logged. The value curve is non-linear: the second provider is where a gateway stops being nice-to-have.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Is an AI gateway a security boundary?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">It is a <em>credential<\/em> boundary, not a user-auth boundary. It protects your provider keys and enforces spend, but it does not do WAF, bot mitigation, or tenant RBAC over your own resources. Keep user authentication at the API gateway and treat the AI gateway as an internal service.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Does adding an AI gateway hurt latency?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A well-built gateway adds single-digit milliseconds of routing overhead \u2014 noise next to a multi-second model call \u2014 and the semantic cache usually <em>reduces<\/em> median latency. The real risk is buffering in the streaming path, not the extra hop. Verify with time-to-first-token, since buffering is invisible in averages.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">An API gateway and an AI gateway are not competitors. One governs who reaches your services; the other governs which model answers each prompt, what it costs, and what happens when a vendor fails. The overlap is shallow \u2014 auth and request limits, both of which the edge does better. The gaps are deep: token budgets, cross-vendor failover, streaming correctness, prompt-logging policy, and semantic caching cannot be bolted onto an HTTP proxy. For a public application that calls models, the default is both, in that order.<\/p>\n\n\n\n\n<h3 class=\"wp-block-heading\">Related reading<\/h3>\n\n\n<ul class=\"wp-block-list\"><li><a href=\"https:\/\/qoraapi.com\/blog\/ai-api-gateway-guide\/\">What Is an AI API Gateway? A Practical Guide for Developers<\/a><\/li><li><a href=\"https:\/\/qoraapi.com\/blog\/best-ai-api-gateway-2026-guide\/\">Ultimate Guide: How to Choose the Best AI API Gateway in 2026<\/a><\/li><li><a href=\"https:\/\/qoraapi.com\/blog\/switch-ai-providers-unified-gateway\/\">How to Switch AI Providers Without Rewriting Your Code<\/a><\/li><li><a href=\"https:\/\/qoraapi.com\/blog\/ai-api-failover-multi-provider\/\">How to Build a Multi-Provider AI Failover Layer for 99.9% Uptime<\/a><\/li><\/ul>\n\n","protected":false},"excerpt":{"rendered":"<p>AI gateways and API gateways overlap but solve different problems. Here&#8217;s how they differ, where each sits in your stack, and when to use which.<\/p>\n","protected":false},"author":1,"featured_media":129,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[5,6,9,7],"class_list":["post-130","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai-api","tag-ai-api","tag-api-gateway","tag-developer-tools","tag-developers"],"_links":{"self":[{"href":"https:\/\/qoraapi.com\/blog\/wp-json\/wp\/v2\/posts\/130","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/qoraapi.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/qoraapi.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/qoraapi.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/qoraapi.com\/blog\/wp-json\/wp\/v2\/comments?post=130"}],"version-history":[{"count":1,"href":"https:\/\/qoraapi.com\/blog\/wp-json\/wp\/v2\/posts\/130\/revisions"}],"predecessor-version":[{"id":171,"href":"https:\/\/qoraapi.com\/blog\/wp-json\/wp\/v2\/posts\/130\/revisions\/171"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/qoraapi.com\/blog\/wp-json\/wp\/v2\/media\/129"}],"wp:attachment":[{"href":"https:\/\/qoraapi.com\/blog\/wp-json\/wp\/v2\/media?parent=130"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/qoraapi.com\/blog\/wp-json\/wp\/v2\/categories?post=130"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/qoraapi.com\/blog\/wp-json\/wp\/v2\/tags?post=130"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}