I just got an error 500 on the hosted version at invoicing.co
I think it’s related to the webhooks we’re currently testing…
The payment was processed but the webhook didn’t complete it’s steps at our end, so is there any way to have a look at the logs please?
Hi @bruce
We’d need a lot more info to look at this, can you send us an email contact@invoiceninja.com along with what you were doing, and what you were expecting?
The webhook just sends a payload of data, so i don’t think you would receive a 500 from that?
Cool, I’ll ask @Amit.Panchal to take a look at things on our side and get back to you with more info/questions as needed…
Hi @david
Webhook is getting “plan_expired” as given below. What could be a reason and how to fix it?
{"body":{"context":"plan_expired","client":"pmbk4Nkvdz","invoice":"y1aKwp7MaQ","subscription":"k8mep2rbMy"}}
Ideally, payment shouldnt be allowed for an expired plan. Hence we are interested to know the possible reasons, so that we can take further actions.
This is a helper webhook which notifies you when a subscription invoice has gone past its due_date
You should be able to handle this by switching on the ‘context’ key
Hi @david ,
We’ll handle it in our application. But question is why payment is allowed in IN for an expired subscription ?
What changes do we need to make in subscription, so that it wont expire for a long time ?
Another question, what are other type of such requests? I did ask the same question earlier (below link) and still didnt get the answers. We’ll need list of all possible events, so that we can handle it in our application.
With “plan_expired”, we’ll have to spend few more hours in implementing it followed by a testing of all the cases (even for tests that passed earlier). Hope you understand the point about efforts in rework/retest and share the list of all the events, so that we can analyse all together and plan our work accordingly. And yes, it will also minimize question for you guys from our end.
Thanks,
Amitkumar
These are the potentials contexts
case 'trial':
case 'recurring_purchase':
case 'single_purchase':
case 'change_plan':
case 'cancellation':
case 'is_eligible':
case 'plan_expired':
case 'plan_paid':
You can set the subscription to expired based on the frequency of the subscription
frequency_id is a const
/**
* Invoice Frequencies.
*/
const FREQUENCY_DAILY = 1;
const FREQUENCY_WEEKLY = 2;
const FREQUENCY_TWO_WEEKS = 3;
const FREQUENCY_FOUR_WEEKS = 4;
const FREQUENCY_MONTHLY = 5;
const FREQUENCY_TWO_MONTHS = 6;
const FREQUENCY_THREE_MONTHS = 7;
const FREQUENCY_FOUR_MONTHS = 8;
const FREQUENCY_SIX_MONTHS = 9;
const FREQUENCY_ANNUALLY = 10;
const FREQUENCY_TWO_YEARS = 11;
const FREQUENCY_THREE_YEARS = 12;
Thanks for the information and sorry for delayed reply.
We have implemented webhooks for different contexts to support multiple companies.
We noticed another issue. Let me brief you about it.
We have two companies configured. We configured few subscriptions along with a webhook for both the companies. We are also getting requests whenever client from either company made a payment for a subscription. Application is invoking respective apis (for ex. login, clients, statics, logout etc) using companies url. For one company say (FG Testing), we are getting client information for the client mentioned in a webhook. However, for another company (FG NA1), we are getting below response whenever we invoke the api (https://company2.invoicing.co/api/v1/clients/Ab123c4de5).
{“message”:“You are not authorized to view or perform this action”}
Could you please help us to understand what could be a reason for this error?
Please note that before invoking client api, application is signing in with login api (https://company2.invoicing.co/api/v1/login).
Are we missing any configuration in a company2 to enable to apis or anything else ?
Application follows below steps to process the webhook for all the companies.
Above steps works for Company 1, but we are getting aforementioned message (You are not authorized to view or perform this action) in step 5 for Company 2.
Please do let us know if you want us to share more details.
Thanks in advance,
Amitkumar
Are you using company1 token for company2 requests? this sounds like the issue.
To test, use company2 token and CURL to verify.
Hi @david ,
No, we are retrieving token before every request as mentioned earlier. We also using company specific URLs to invoke the APIs. So, using other company’s token is not a case here, hence we wrote to you.
Thing is everything working as expected for Company1, but client API doesnt return client info for Company2 (only step 5 in above steps).
Any pointers ? Let us know if you need more ddetails.
How are you retrieving a token for every request?
For token we are calling below url (login api)
Company 1: https://company1.invoicing.co/api/v1/login
Company 2 : https://company2.invoicing.co/api/v1/login
Once we get the response, we are picking up token from the token section (as per the sample below).
> "token": {
> "id": "y1aKrPPGeQ",
> "user_id": "WPe9wGDbLy",
> "token": "<TOKEN USED FOR AUTHENTICATION>",
> "name": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36",
> "is_system": true,
> "updated_at": 1645627434,
> "archived_at": 0,
> "created_at": 1645627434,
> "is_deleted": false
> }Could you please provide pointers on our issue ? We have set up 2 companies. Application is processing payment for clients for both the companies with company specific urls as mentioned below. We dont see any issues for company1. But we see “unauthorised to perform” error for company2.
APIs by company1.
https://company1.invoicing.co/api/v1/login
https://company1.invoicing.co/api/v1/clients/{CLIENTID}
https://company1.invoicing.co/api/v1/statics
https://company1.invoicing.co/api/v1/logout
APIs by company2.
https://company2.invoicing.co/api/v1/login
https://company2.invoicing.co/api/v1/clients/{CLIENTID}
https://company2.invoicing.co/api/v1/statics
https://company2.invoicing.co/api/v1/logout
We’ll need your help to get pointers to understand why everything is working fine for company1, but not for company2.
Are you sending requests to different URLs? This shouldn’t be required. You should send everything to invoicing.co just with company specific tokens
Thanks for your reply.
Yes. Different URLs, based on company subdomain, for different companies. Its working fine with first company, so we enhanced our application to support multiple company.
Based on your reply, this is not the right way. We understood the url will remain same for all companies but token will be different for each company. If so, please help us for below:
So that we can make necessary changes to our application.
That’s correct.
You can create tokens in the app on Settings > Account Management.
Thanks for your reply and help.
Quick update. We made the changes in our application based on your valuable inputs and it worked well. Application is receiving webhook requests without any error related to authorization (as mentioned in the earlier messages).
However, we noticed below for the request received for different companies.
Company1 - No issue in our application as well as in IN. Smooth processing.
Company2 - No issue in our application. But on IN, we see error 500 even after success response from our application.
Could you please help us by providing any pointers ? Any issue related to timeout? Earlier we were not reaching to this stage bcaz of authorization error, now we made progress, but got error 500 only for company2. Hence we’ll need your inputs.