[HN Gopher] Tell HN: Instagram's API has broken, support tickets...
___________________________________________________________________
Tell HN: Instagram's API has broken, support tickets ignored,
status page green
Meta offers an OAuth based API for Instagram. Many companies and
tools are built on and rely on this API for their product & daily
operations. Beginning Friday evening (US time), a critical
endpoint in this API has broken. The endpoint creates long-lived
access tokens, so it is in the critical path for almost any company
using the API. I find it disappointing that a leading
technological company does not acknowledge a bug that's been
reported to them several times more than 24 hours ago, even if to
say that's it's being investigated. The endpoint:
https://developers.facebook.com/docs/instagram-basic-display-
api/guides/long-lived-access-tokens#get-a-long-lived-token
Currently the API returns a Bad Request with a wrong error message
(the endpoint should support "GET"): ``` { "message": "Unsupported
request - method type: get", "type": "IGApiException", "code": 100,
"fbtrace_id": "AuDYqK74IrT9Yt2Sx51UlP6" } ``` I have opened a bug
report but received no response. Facebook's status page shows all
green in the API section: https://metastatus.com/ There are several
Meta Developers Community threads with no response
Author : PeledYuval
Score : 147 points
Date : 2023-03-19 08:58 UTC (14 hours ago)
| VWWHFSfQ wrote:
| > Many companies and tools are built on and rely on this API for
| their product & daily operations.
|
| Will you people ever learn.
| 0xfacfac wrote:
| lol Did Elon acquire Instagram too?
| hislaziness wrote:
| Impact of the layoffs?
| Arbortheus wrote:
| GET for creating access tokens seems like the incorrect request
| type.
| dbalatero wrote:
| Oddly their docs use GET though
| https://developers.facebook.com/docs/instagram-basic-display...
| contravariant wrote:
| Using GET to request a resource, kind of makes sense. Usually
| you want to send some information to the endpoint as well
| though, which makes a GET a bit awkward.
| jeroenhd wrote:
| GET should be idempotent, so if the request is repeated by
| the browser/a proxy/a user hitting F5, it should not matter.
| This is why some websites with inadequate password reset
| email links don't work if your company/ISP/email provider
| implements link scanning, as the automated service already
| clicked the super secret one-time link (and if the website is
| following the spec, that should be totally fine).
|
| As long as the GET requests returns the same or equivalent
| API data every time they make total sense. For an access
| token, that's perfectly fine, assuming they don't generate a
| new token with every request of course.
| i386 wrote:
| Welcome to Meta API
| nkozyra wrote:
| > Many companies and tools are built on and rely on this API for
| their product & daily operations.
|
| Hopefully not their entire product. The first rule is don't build
| your company on the back of another, but I think the most
| important part is that if you _do_ use another company, make sure
| you 're fine if they disappear one day.
|
| The last time Facebook made major changes (ostensibly as a
| response to the Cambridge Analytica stuff, but that was just an
| excuse) a bunch of people got burned.
|
| My company did too but we always kept ourselves in a place where
| if it vanished we'd be - at worst - inconvenienced.
|
| This approach came because early on I was burned by Twitter
| changes that were more impactful.
|
| Most recent Twitter changes prove that even paying for access
| provides no guarantees.
| omk wrote:
| True. The Twitpic story comes to mind.
| princevegeta89 wrote:
| Sorry but APIs aren't meant to be broken at anytime. That's
| what they are for. That is the unwritten part of the so called
| contracts/agreements.
|
| I do not understand how the idea of not building a company on
| the back of another is possible. We rely on other companies for
| deployments, hosting, reporting, monitoring, payments, billing
| and security etc. Some may be less critical than others but how
| can you avoid your reliance on other companies at all?
| kaetemi wrote:
| Ensure you have a backup supplier that you can switch to.
| j45 wrote:
| Very true. It's a small but very helpful act of looking out
| for your future self to generalize access to APIs or
| multiple providers in your codebase via your own concept of
| accessing a list of service providers can be easily swapped
| out or added to.
| brookst wrote:
| It's about diversification. Don't build a company entirely
| dependent on a single other company that can't be replaced.
|
| If your payment provider stops offering payments, it's
| annoying but not existential. If your whole business is
| reselling a single artist and they die or switch to a
| different gallery, you're done.
| marpstar wrote:
| GP's advice generally applies when talking about integrating
| with a third party API to provide data as a "input" to your
| business. The things you listed (deployment, hosting,
| monitoring...) are all after-the-fact concerns, and are
| generally interchangeable in a way that the API output schema
| (or systems uptime) for a particular service is not.
| WA wrote:
| I have the same attitude and it is severely restricting my
| creativity. While I think "don't build on other peoples APIs",
| others just launched many tools built on top of Instagram,
| OpenAI, Twitter and whatnot.
|
| By now I feel like it's better to build on top of an API, be
| aware that it might go away one day but make money while it
| lasts, which can be many years.
| i386 wrote:
| this is easy to say as a comment on HN but unavoidable to a
| large degree for businesses in the marketing and social media
| space.
| nkozyra wrote:
| Well these are riskier businesses to start for this reason.
|
| I did cage it by saying make sure your whole company doesn't
| collapse if one API gets shut down.
| Waterluvian wrote:
| Yeah, I don't think it's right to say "never try." It's more,
| "never lose sight at how brittle your business is. The other
| company owes you nothing if it's not written in a contract.
| You aren't a victim when it breaks your business."
| dylan604 wrote:
| you play in the mud, you're going to get dirty. if your
| entire marketing company focuses on social, then why that
| doesn't fall into "all eggs, one basket" concept is beyond
| me. Sure, it's much easier to get a company rolling when you
| have to do nothing but use the product of someone else as the
| core of your business, but why that's not an immediate red
| flag to someone in that position is something i just don't
| understand.
| BoorishBears wrote:
| This has got to be the most platitudes I've ever seen
| stuffed in a single comment... I almost want to say it's
| satire.
|
| But yeah, there's a lot of real valuable businesses built
| on existential risks. We're currently getting a reminder
| that our banking system puts all its eggs in the idea not
| too many people will ask for money at the same time.
|
| Optimizing for black swan events is just generally not good
| business.
| lozenge wrote:
| Marketers and customer service need to be able to manage
| their social accounts, that's a product space which
| inherently relies on API access to those website. Maybe you
| wouldn't want to build that product, but clearly somebody
| will.
| uoaei wrote:
| That is a risk of doing business. If they don't anticipate
| this kind of thing and build contingencies around it, they
| are simply bad at business.
|
| "Free market for thee, but not for me" is not a strong
| argument in any context.
| i386 wrote:
| Risk without risk mitigation is just bad business.
| BoorishBears wrote:
| You don't understand risk or business if you think a good
| business mitigates all risks, or even its largest risks.
|
| The biggest risk for a medical company is harming
| patients. Do they just throw up their hands and stop
| being a medical company?
|
| The biggest risk for social media firm is the social
| media they serve through goes down. So what, they throw
| up their hands and stop being a social media firm?
| i386 wrote:
| Absolutely not what I am saying, please read up.
| LadyCailin wrote:
| Part of these types of businesses is accepting that risk
| then, and knowing that despite doing everything right, your
| business may be unceremoniously shut down because of some
| PM's whim. I wouldn't want to be in that kind of position,
| but I guess more power to those that do.
| paulddraper wrote:
| > The first rule is don't build your company on the back of
| another
|
| What's the over-under on # of companies built on AWS?
| reddec wrote:
| Did you try POST (regardless of docs)?
| 360macky wrote:
| Oh that's awful. I'm developing my first app with Instagram
| Display API.
| gregjor wrote:
| Good news, like shutting off a leaky sewer pipe.
| unxdfa wrote:
| That's the best description I've heard for instagram.
| adhesive_wombat wrote:
| Not really, since it implies the "leak" is unintentional.
| Traubenfuchs wrote:
| It's calming to see that even big tech is unable to properly
| manage their APIs including completely useless error massages and
| communication silence.
| never_inline wrote:
| Diseconomies of scale.
| mjdowney wrote:
| There is nothing more frustrating than a status page that lies
| about the state of an API. Feels like insult + injury. I'd rather
| they not even have a status page!
| xwdv wrote:
| Unfortunately almost all status pages are for gaslighting
| purposes when things get _really_ bad.
|
| Easier to tell a developer they're crazy and their code was
| wrong than to admit to downtime and violate any SLAs.
| s1k3s wrote:
| I mean, Meta's developer terms literally say you agree they can
| take your product at any time and turn it in their own product
| without prior notification. And that's on top of "we can change
| anything, we can cut out your access at any time" etc. So yeah,
| do you really expect anything from these companies? Don't make
| your product rely on them.
| jurassic wrote:
| I feel like "thing broken, status page green" has almost become a
| meme at this point. We need to do better here.
| barbazoo wrote:
| Not sure if they fixed it yet but starting a month or so ago FB
| disabled creating test users which broke our release process in
| one corner of the org. Same thing you mentioned, lots of bug
| reports, no response other than boilerplate 1st level support.
|
| I don't mind it though, long term that's good news as it'll let
| us remove any dependencies we have on FB.
| xkcd1963 wrote:
| They created a complete mess. One would think such a high
| prestige employer would employ competent managers and software
| developers, but that does clearly not translate to what they
| produce. Lots of words, little deeds. And then they decide to lay
| off people and it apparently makes it only worse.
| moneywoes wrote:
| Is it only your product?
| mangotab wrote:
| [dead]
| jeroenhd wrote:
| I don't know what you've already checked, but the lowercase `get`
| in the error message seems suspicious. Are you sure you're
| sending a `GET` and not a `get`? HTTP verbs are case sensitive,
| after all.
| i386 wrote:
| My startup is a consumer of the Graph API for Instagram (OP
| appears to be using Dispay API). We have about 1000 loc that just
| deal with weird user specific bugs in their API and it's
| impossible to give feedback about it to anyone at Meta.
|
| OP - is there a way to contact you? Drop me a DM on ig
| Instagram.com/i386 I may be able to help with a workaround
| benguild wrote:
| Instagram's API tokens constantly expire for me regardless of
| whether they're supposed to be "long-lived" or not. They last
| like 90 days which is super annoying.
| i386 wrote:
| You need to keep using the tokens for them to remain valid.
| Have a daily job that fetches the users basic profile info like
| /accounts/me to keep them valid
| mrloop wrote:
| I'm building an integration that will use a long lived token
| once a month. In your experience will a long lived token
| expiry if not used for a month? How long do they remain valid
| until expiring from not being used?
| i386 wrote:
| About three months for long lived tokens in my experience.
| My recommendation would be to use them weekly.
| Graphguy wrote:
| Status page seems updated now.
| Animats wrote:
| Your problems mean nothing to us, puny startups!
| the_gipsy wrote:
| Ooh, did someone get addicted to crack? _mocks tears_
|
| Don't build on platforms, build on protocols.
| twodave wrote:
| Status pages aren't for providing transparency or customer
| service or anything else besides enforcing contracts.
| luxuryballs wrote:
| The FBI must have warned them about some upcoming Russian
| propaganda /s
| turnsout wrote:
| I really hope more users discover Pixelfed. As a developer, it
| was so easy to work with (99% people of the time just treat it
| like the Mastodon API).
| zimpenfish wrote:
| I'm hoping that someone makes a Pixelfed-alike with a sane
| stack like Elixir or Go. The installation guide is just a bit
| too long and faffy for me right now.
| turnsout wrote:
| If enough people show up, that will happen, just like it has
| with Mastodon
| fsckboy wrote:
| I'll try to give different advice from what I see here: if you
| build your company on Istagram's API, make sure the network
| effects of your product encourage use of Instagram and that use
| benefits its owners; then they won't want your access to go away.
| greatjack613 wrote:
| Did you double check that other people are having this issue?
| Seems very likely that this could be something affecting just
| your access key or something like that
| tdy721 wrote:
| This one, a single report does not an outage make.
| i386 wrote:
| It seems to be affecting a lot of people using Instagram
| Display API but not the Instagram Graph API. Loads of
| reports.
|
| https://developers.facebook.com/support/bugs/743806503999661
| meghan_rain wrote:
| Well, did you try a POST?
| egberts1 wrote:
| Meta (Facebook/Instagram) must have not taken the Twitter route
| during their mass layoffs.
|
| You cut non-essential folks firstly and critical operational
| personnel lastly.
| kleinsch wrote:
| Nice snark, but layoffs in Nov were primarily business, most
| recent round doesn't actually start in tech until April.
| paxys wrote:
| You are right the Twitter API is so usable right now..
| femiagbabiaka wrote:
| Twitter didn't take that route either.
| blululu wrote:
| They probably tried to do that but without a complete
| understanding of who does what exactly. Imagine a clueless
| manager lists out who on their team does what. Imagine the
| clueless manager got canned and now someone one or two steps
| removed needs to assess who does what. You don't get to a
| layoff by being a well managed org, so you typically don't
| execute the layoff very well.
| cldellow wrote:
| I gather you haven't tried to use the Twitter Ads API lately.
| :) This is literally an API that makes it easier for people to
| give money to Twitter. And yet it's seemingly abandoned since
| the Musk takeover, with the old documentation taken down and
| the support forums ignored.
| pacifika wrote:
| [flagged]
___________________________________________________________________
(page generated 2023-03-19 23:03 UTC)