When integrating our system with a 3rd party company to use their billing system, we had a Hangouts chat so we could ask things about their documentation, API, etc...

Me: *explain the problem and how I tried to solve it without success, and proceed to ask 3 things*

*2h of silence*

3rd.p: Good Morning
Me: Good Morning
*another 2h of silence*

Me: ...and?
*1h of silence*

3rd.p: *answer randomly one of the questions*
Me: ok, and the other two questions?

*silence until the next day*

Me: ???
3rd.p: *answer one question and says that the other will never happen*
Me: but... I've just sent a request to your backend and it happened!!!

*2h of silence*

3rd.p: No, you are reading this wrong, we didn't respond that
Me: This is the endpoint i'm calling and the request's payload, send this to your backend.

*silence until the next day*

(and this continues to almost 2 months to complete the integration that should not need more than 1 week)

@tokenguy maybe the token was wrong 😂

@myss I also have a story with the same company and tokens... they asked us to generate a long secret token so the backends could communicate in a secure way. We asked them if they have any kind of limitations or format for the token, and they said that they didn't have any besides the token wold be sent on the header 'Authorization'.

So we create a string with 128 chars and every request from them we checked if they sent this string on the header (if no, we returned HTTP 401).

On their first test they said that we were answering 401 for every request. Obviously we told them to check the token, and they said that everything was ok.

Since we're already used to their common "we are SO right that we will not even check" behavior, we implemented a Log feature, to log their entire request.

The 'Authorization' header value was "Bearer <64-char string>". We told them. They said "oh... yeah... we only accept 64-char tokens, and we always send "Bearer "on the beginning.

Async chat in a nutshell 😂