Can You Change Discord's GIF API? What You Can Actually Do

Can you change which GIF provider Discord uses? The short answer is no. Here is what you can do instead, with and without admin rights.

Can You Change Discord's GIF API? What You Can Actually Do

The Tenor API died on June 30, 2026, and if you shipped a GIF picker on top of it, your search results died with it. The good news: migrating to a new provider in 2026 is genuinely a small job, because two of the three surviving options were built specifically to catch Tenor refugees. Here is what the migration actually involves, which path to pick, and where people got burned.

Your three options

After June 30 there are exactly three real choices:

  • Klipy, built by the ex-Tenor founding team as a drop-in replacement. You change a base URL and an app key and you are done. Used by Discord, WhatsApp and Bluesky's ecosystems. Official migration docs.
  • GIPHY compatibility mode, a Tenor-shaped API layer GIPHY built for exactly this migration. Same endpoints you had, GIPHY data behind them. Their Tenor migration guide.
  • GIPHY native API, the full-featured path with a completely different response shape. More power, more work.

The Klipy path: literally a base URL swap

Klipy copied Tenor's v2 request and response structure on purpose. In practice:

  • Base URL: tenor.googleapis.com becomes api.klipy.com
  • Your API key becomes an app_key from the Klipy partner panel
  • The results array and next pagination token keep the same names and semantics

The Klipy co-founder put it plainly in the r/discordapp migration thread: "We've also built 10 minute migration guide from Tenor to KLIPY that only requires base URL swap." Marketing claim, but it checks out against their docs.

There is a catch worth knowing: the free tier is ad-supported. Klipy inserts programmatic ads into GIF results and shares revenue with you. For a hobby app that can be a feature, for a polished product it may not fit.

The GIPHY path: two doors, one trap

GIPHY's compatibility layer maps Tenor's key to a GIPHY key and treats the pos cursor as opaque. Two Tenor features do not survive: searchfilter=static and ar_range.

Go native instead and the response contract changes entirely: results becomes data, the next token becomes a numeric offset, and Tenor's single registershare call becomes three per-GIF tracking URLs (onload, onclick, onsent) that you are expected to fire. Also mind the content filter mismatch: Tenor used off/low/medium/high, GIPHY uses MPA-style ratings, so your filter mapping needs a small bridge.

The trap every dev hits: all new GIPHY keys are Beta keys capped at 100 requests per hour. Production limits require an application with a manual review. Ship your picker on a Beta key and it will fall over in testing. That is the number one complaint in every migration thread.

If you used a picker component

If your integration is the popular gif-picker-react component, version 2 added provider classes so the swap is a one-liner:

import { GifPicker } from 'gif-picker-react';
import { Klipy } from 'gif-picker-react/providers/klipy';

<GifPicker provider={Klipy("YOUR_KLIPY_APP_KEY")} />

GIPHY and Tenor-legacy providers ship the same way, which makes A/B testing providers trivial.

What devs actually said during the migration

The r/discordapp thread where Discord's Klipy tests were spotted turned into the best public post-mortem:

"Variant 0: Tenor, Variant 1: Giphy (Actual Trash), Variant 2: Klipy"u/MechE__

The analytics loss stung more than people expected:

"This is killing me that I'll no longer know how many times my gifs are shared... giphy and klipy do not have share totals for their gifs"u/CodElectrical5233

Video walkthroughs if you want to watch one first

For a Discord bot command specifically, Wisp's GIF search command tutorial shows the bot-side wiring, and Steve Griffith's GIPHY API deep dive covers the native response handling end to end.

My take

Reading every migration thread, the pattern is consistent: teams that picked Klipy finished in an afternoon and mostly complained about ads; teams that picked GIPHY finished in a week and complained about everything else, the Beta rate limit above all. If search quality in your niche matters, test it with your actual users' search terms before committing, because GIPHY's library has real gaps. The r/discordapp crowd said it best:

"Welcome to giphy, where all the gifs are targeted towards boomer moms and every relevant gifs are either replaced by benjammin or requires you to know the uploader's name."u/PiscesSoedroen

And the longer-term lesson from this whole mess: an API you do not control is a dependency you will re-live. For content itself, not just search, the sturdier answer is building your own GIF library instead of renting one.

If your product makes GIFs rather than just serving them, that is what we built the 8gifs composer for: paste a screenshot, URL or tweet, get a looping pixel-art GIF you host yourself.


Related: what actually happened to the Tenor API, what changed in Discord's own picker, and the honest rundown of every Tenor alternative.

Provenance: API specifics from Klipy and GIPHY official docs (July 2026), migration experiences from r/discordapp threads and Hacker News, linked inline. Search-demand context for this cluster is [est].