Automatic external Invoice Creation by calling SuiteCRM API

👨‍💻 Development Help
1

Hello and Good Evening,

long working on perfect SuiteCRM installation. Now i want to Open up another thing - automatic Invoice Creation, based on an api call, as i actually are not very into api programming (but i am experienced in php some years ago) so i am running through dark forrest at the moment and propably I need your start-push.

  1. how can i call the api properly for getting done first steps?
  2. how can i start creation of a new invoice by it?
  3. can i also find some services/products in suitecrm database for sum it up with the given numbers of the api call or do i need other ways for this and is it possible to filter these feedback-values?
    (e.g i have a product 2018-05-name, 2019-02-name, 2019-08-name, and 2020-04-name it should use 2020-04-name as it is the last?
  4. non dev question: how can i set up a standard due date in suitecrm?
  5. how can i automatically send emails with these invoices? Or can i show all “created but not send invoices” somehow? (i actually just saw paid and non paid in reports yet)

thanks in advance :slight_smile:

2

Your start point for the V8 API is here:

There are a number of ‘gotchas’ with this that I’ve highlighted over the past few weeks. Once you have the API working, then you can move forward to the next bit (the invoicing) which will depend on your specific setup.

3

ok, then i’ll begin it :slight_smile: (why ever i already read something about api v4…so better ask then running even deeper into the dark forrest :slight_smile: )

thanks

4

Hi Anothermouse,

so i am running against first wall. i did as shown here https://docs.suitecrm.com/developer/api/developer-setup-guide/configure-authentication/

but the only thing i get is 404 not found…furthermore, if i adress /Api/access_token (do i need to change that?) also 404, or do i need some rewriting there? :?

Thanks

5

As expected:)

Did you manually copy over your .htaccess?
Have you got mod_rewrite enabled?
Have you configured it correctly - you need to have created the keys, and have an https connection for the OAuth to work:

How to use with Postman
https://docs.suitecrm.com/developer/api/developer-setup-guide/suitecrm_v8_api_set_up_for_postman/

Once you have done this, you may hit another issue in that if you copied the .htaccess over, then it won’t work correctly, as the config in the web installer is not correct. See:
https://github.com/salesagility/SuiteCRM/issues/8827

As a result, I’ve detailed the alternative URLS at the end of:
https://community.suitecrm.com/t/request-to-api-return-404-error/65657/29

-------8x-------------
I guess that I ought to put the direct URLs here as well for the latest 7.10.x and 7.11.x versions of the software. The .htaccess file relies on mod_rewrite (in apache) to carry out the following URL changes:

RewriteRule ^Api/(.*)$ - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteRule ^Api/access_token$ Api/index.php/access_token [L]
RewriteRule ^Api/V8/(.*?)$ Api/index.php/V8/$1 [L]

This means that you can avoid the shortened https://mysite.com/Api/access_token and instead use the full path https://mysite.com/Api/index.php/access_token

Similarly for using the V8 Api, replace https://mysite.com/Api/V8/module and instead use the full path https://mysite.com/Api/index.php/V8/module

This way, you should still get the desired REST connection, even if the rewrite rules/.htaccess etc is messed up in some way.
-------8x-------------

1 Like
6

Sorry, working on nginx, so htaccess wouldn’t work, and reading now the 10th page about how to configure nginx, but had also did the way it was stated here (suiteCRM nginx config) before.

yes, https is working since several time, keys are generated…but it seems to be an issue before

7

By the way even before i noticed in composer update that there are several deprecated things in it, can i clean them out or are they neccessary to suite?

8

I know the feeling - I also like to tidy things up from time to time. I’d recommend getting it to work before clearing out anything, as if you clear everything out, you could plausibly break something and never know it? Once it’s working you can clear out something step by step. If something breaks then put it back.

As you’re using nginx, you need to try the full (un mod_rewrited?) URLs:
https://mysite.com/Api/index.php/access_token
https://mysite.com/Api/index.php/V8/module

If you want it to work on the ‘standard example URLS’, then you’ll need to modify the nginx config. This may help:

…but in the spirit of trying to make the system work in the most generic way possible with cross server compatibility, then let’s ignore that and try and go for using the direct URLs

9

propably the hard way to go if you are not feeling comfortable with a system yet and want to see all unclean details :slight_smile:

so i wanted to go the way via index.php/access_token, still it says 404, at me check.php file - “echo ‘test’;” is given back successfull, but echo $output gives me just the standard nginx 404…

could there be sth corrupt in that suitecrm installation or do i need other preparation stuff?

10

You shouldn’t use composer update, it will take software dependencies past the versions that are tested with SuiteCRM. This can generate serious problems.

You should just use composer install --no-dev

And don’t worry about the deprecated messages, it’s true they need action, but it’s not clearing them out (that will leave holes in the software), it’s adapting the existing core code to require newer (or different) libraries. This is continuously being done, but it keeps needing more. It’s the natural flow of software growing old with time :slight_smile:

11

Just to show you what I get on my system for index.php and for the access_token URL

access_token2020-07-26 16-42-53
access_token2020-07-26 16-42-532560×1440 179 KB
index.php2020-07-26 16-41-51
index.php2020-07-26 16-41-512560×1440 167 KB

Note that this is a DIFFERENT ‘Page Not Found’ to the standard 404 (,but being aware of this gives you a very quick way to test in your browser whether your changes have fixed the problem).

Also note that Api IS CASE SENSITIVE!

If that isn’t working, then time to check permissions on the files concerned, and after that you’ll need to increase the web server logging levels in order to locate the cause of the issue.

12

yep, i got that, also the case. but it’s not running properly…i have even to get on a deep dive there

13 
 location ~ /Api/ {
            index   index.php;
            try_files $uri @rewrite_api;

            location ~ \.php {
                    include snippets/fastcgi-php.conf;
                    fastcgi_pass unix:/run/php/php7.4-fpm.sock;
            }
    }

    location @rewrite_api {
            rewrite ^/Api/(.*)?$    /Api/index.php/$1       last;
    }

done

14

i will notice that and hope i didn’t break anything

@anothermouse thanks for help, i got now a working connection :smiley: in 10 Years perhabs it will run fine :smiley:

1 Like
15

@chriswithadot - NP, and thanks for posting the nginx solution that you used as it will help people in future.

1 Like