Replace the api docs link with the correct one

README.md

@@ -34,7 +34,7 @@ Browsable HTML docs http://readthedocs.org/docs/cgrates/
 
 PDF, Epub, Manpage http://readthedocs.org/projects/cgrates/downloads/
 
-API reference [godoc](https://godoc.org/github.com/cgrates/cgrates/apier)
+API reference [godoc](https://pkg.go.dev/github.com/cgrates/cgrates/apier@master)
 
 Also check [irc.freenode.net #cgrates](irc://irc.freenode.net:6667/cgrates)  ([Webchat](http://webchat.freenode.net?randomnick=1&channels=%23cgrates)) and [Google group](https://groups.google.com/forum/#!forum/cgrates) for a more real-time support.
 

docs/apicalls.rst

@@ -3,5 +3,5 @@ API Calls
 
 API calls are documented in the following GoDoc_
 
-.. _GoDoc : https://godoc.org/github.com/cgrates/cgrates/apier
+.. _GoDoc : https://pkg.go.dev/github.com/cgrates/cgrates/apier@master
 

docs/attributes.rst

@@ -3,7 +3,7 @@
 AttributeS
 ==========
 
-**AttributeS** is a standalone subsystem within **CGRateS** and it is the equivalent of a key-value store. It is accessed via `CGRateS RPC APIs <https://godoc.org/github.com/cgrates/cgrates/apier/>`_.
+**AttributeS** is a standalone subsystem within **CGRateS** and it is the equivalent of a key-value store. It is accessed via `CGRateS RPC APIs <https://pkg.go.dev/github.com/cgrates/cgrates/apier@master/>`_.
 
 As most of the other subsystems, it is performance oriented, stored inside *DataDB* but cached inside the *cgr-engine* process. 
 Caching can be done dynamically/on-demand or at start-time/precached and it is configurable within *cache* section in the :ref:`JSON configuration <configuration>`.

docs/cdre.rst

@@ -10,7 +10,7 @@ CDRe
 ====
 
 
-**CDRe** is an extension of :ref:`CDRs`, responsible for exporting the *CDR* events processed by :ref:`CDRs`. It is accessed via `CGRateS RPC APIs <https://godoc.org/github.com/cgrates/cgrates/apier/>`_ and configured within *cdre* section inside :ref:`JSON configuration <configuration>`.
+**CDRe** is an extension of :ref:`CDRs`, responsible for exporting the *CDR* events processed by :ref:`CDRs`. It is accessed via `CGRateS RPC APIs <https://pkg.go.dev/github.com/cgrates/cgrates/apier@master/>`_ and configured within *cdre* section inside :ref:`JSON configuration <configuration>`.
 
 
 Export types
@@ -32,7 +32,7 @@ You can control the templates which are to be executed via the filters which are
 Offline exports
 ^^^^^^^^^^^^^^^
 
-Are exports which are triggered via `CGRateS RPC APIs <https://godoc.org/github.com/cgrates/cgrates/apier/>`_ and they have as data source the CDRs stored within *StorDB*.
+Are exports which are triggered via `CGRateS RPC APIs <https://pkg.go.dev/github.com/cgrates/cgrates/apier@master/>`_ and they have as data source the CDRs stored within *StorDB*.
 
 
 

docs/cdrs.rst

@@ -4,7 +4,7 @@ CDRs
 ====
 
 
-**CDRs** is a standalone subsystem within **CGRateS** responsible to process *CDR* events. It is accessed via `CGRateS RPC APIs <https://godoc.org/github.com/cgrates/cgrates/apier/>`_ or separate *HTTP handlers* configured within *http* section inside :ref:`JSON configuration <configuration>`.
+**CDRs** is a standalone subsystem within **CGRateS** responsible to process *CDR* events. It is accessed via `CGRateS RPC APIs <https://pkg.go.dev/github.com/cgrates/cgrates/apier@master/>`_ or separate *HTTP handlers* configured within *http* section inside :ref:`JSON configuration <configuration>`.
 
 Due to multiple interfaces exposed, the **CDRs** is designed to function as centralized server for *CDRs* received from various sources. Examples of such sources are:
 	*\*real-time events* from interfaces like *Diameter*, *Radius*, *Asterisk*, *FreeSWITCH*, *Kamailio*, *OpenSIPS*

docs/chargers.rst

@@ -5,7 +5,7 @@ ChargerS
 
 **ChargerS** is a **CGRateS** subsystem designed to produce billing runs via *DerivedCharging* mechanism. 
 
-It works as standalone component of **CGRateS**, accessible via `CGRateS RPC <https://godoc.org/github.com/cgrates/cgrates/apier/>`_ via a rich set of *APIs*. As input **ChargerS** is capable of receiving generic events (hashmaps) with dynamic types for fields.
+It works as standalone component of **CGRateS**, accessible via `CGRateS RPC <https://pkg.go.dev/github.com/cgrates/cgrates/apier@master/>`_ via a rich set of *APIs*. As input **ChargerS** is capable of receiving generic events (hashmaps) with dynamic types for fields.
 
 **ChargerS** is an **important** part of the charging process within **CGRateS** since with no *ChargingProfile* matching, there will be no billing run performed.
 

docs/overview.rst

@@ -4,7 +4,7 @@
 .. _Kafka: https://kafka.apache.org/
 .. _redis: https://redis.io/
 .. _mongodb: https://www.mongodb.com/
-.. _api docs: https://godoc.org/github.com/cgrates/cgrates/apier
+.. _api docs: https://pkg.go.dev/github.com/cgrates/cgrates/apier@master
 .. _SQS: https://aws.amazon.com/de/sqs/
 .. _AMQP: https://www.amqp.org/
 .. _Asterisk: https://www.asterisk.org/
@@ -187,7 +187,7 @@ Links
 
 - CGRateS home page `<http://www.cgrates.org>`_
 - Documentation `<http://cgrates.readthedocs.io>`_
-- API docs `<https://godoc.org/github.com/cgrates/cgrates/apier>`_
+- API docs `<https://pkg.go.dev/github.com/cgrates/cgrates/apier@master>`_
 - Source code `<https://github.com/cgrates/cgrates>`_
 - Travis CI `<https://travis-ci.org/cgrates/cgrates>`_
 - Google group `<https://groups.google.com/forum/#!forum/cgrates>`_

docs/rals.rst

@@ -4,7 +4,7 @@ RALs
 ====
 
 
-**RALs** is a standalone subsystem within **CGRateS** designed to handle two major tasks: :ref:`Rating` and :ref:`Accounting`. It is accessed via `CGRateS RPC APIs <https://godoc.org/github.com/cgrates/cgrates/apier/>`_.
+**RALs** is a standalone subsystem within **CGRateS** designed to handle two major tasks: :ref:`Rating` and :ref:`Accounting`. It is accessed via `CGRateS RPC APIs <https://pkg.go.dev/github.com/cgrates/cgrates/apier@master/>`_.
 
 
 

docs/resources.rst

@@ -6,7 +6,7 @@ ResourceS
 
 **ResourceS** is a standalone subsystem part of the **CGRateS** infrastructure, designed to allocate virtual resources for the generic *Events* (hashmaps) it receives.
 
-Both receiving of *Events* as well as operational commands on the virtual resources is performed via a complete set of `CGRateS RPC APIs <https://godoc.org/github.com/cgrates/cgrates/apier/>`_.
+Both receiving of *Events* as well as operational commands on the virtual resources is performed via a complete set of `CGRateS RPC APIs <https://pkg.go.dev/github.com/cgrates/cgrates/apier@master/>`_.
 
 Due it's real-time nature, **ResourceS** are designed towards high throughput being able to process thousands of *Events* per second. This is doable since each *Resource* is a very light object, held in memory and eventually backed up in *DataDB*.
 
@@ -46,7 +46,7 @@ nested_fields
 ResourceProfile
 ^^^^^^^^^^^^^^^
 
-The **ResourceProfile** is the configuration of a *Resource*. This will be performed over `CGRateS RPC APIs <https://godoc.org/github.com/cgrates/cgrates/apier/>`_ or *.csv* files. A profile is comprised out of the following parameters:
+The **ResourceProfile** is the configuration of a *Resource*. This will be performed over `CGRateS RPC APIs <https://pkg.go.dev/github.com/cgrates/cgrates/apier@master/>`_ or *.csv* files. A profile is comprised out of the following parameters:
 
 Tenant
 	The tenant on the platform (one can see the tenant as partition ID).

docs/routes.rst

@@ -10,7 +10,7 @@ RouteS
 =========
 
 
-**RouteS** is a standalone subsystem within **CGRateS** responsible to compute a list of routes which can be used for a specific event received to process. It is accessed via `CGRateS RPC APIs <https://godoc.org/github.com/cgrates/cgrates/apier/>`_.
+**RouteS** is a standalone subsystem within **CGRateS** responsible to compute a list of routes which can be used for a specific event received to process. It is accessed via `CGRateS RPC APIs <https://pkg.go.dev/github.com/cgrates/cgrates/apier@master/>`_.
 
 As most of the other subsystems, it is performance oriented, stored inside *DataDB* but cached inside the *cgr-engine* process. 
 Caching can be done dynamically/on-demand or at start-time/precached and it is configurable within *cache* section in the :ref:`JSON configuration <configuration>`.

docs/sessions.rst

@@ -4,7 +4,7 @@ SessionS
 ========
 
 
-**SessionS** is a standalone subsystem within **CGRateS** responsible to manage virtual sessions based on events received. It is accessed via `CGRateS RPC APIs <https://godoc.org/github.com/cgrates/cgrates/apier/>`_.
+**SessionS** is a standalone subsystem within **CGRateS** responsible to manage virtual sessions based on events received. It is accessed via `CGRateS RPC APIs <https://pkg.go.dev/github.com/cgrates/cgrates/apier@master/>`_.
 
 
 Parameters

docs/stats.rst

@@ -6,7 +6,7 @@ StatS
 
 **StatS** is a standalone subsystem part of the **CGRateS** infrastructure, designed to aggregate and calculate statistical metrics for the generic *Events* (hashmaps) it receives.
 
-Both receiving of *Events* as well as *Metrics* displaying is performed via a complete set of `CGRateS RPC APIs <https://godoc.org/github.com/cgrates/cgrates/apier/>`_.
+Both receiving of *Events* as well as *Metrics* displaying is performed via a complete set of `CGRateS RPC APIs <https://pkg.go.dev/github.com/cgrates/cgrates/apier@master/>`_.
 
 Due it's real-time nature, **StatS** are designed towards high throughput being able to process thousands of *Events* per second. This is doable since each *StatQueue* is a very light object, held in memory and eventually backed up in *DataDB*.
 

docs/thresholds.rst

@@ -4,7 +4,7 @@ ThresholdS
 ==========
 
 
-**ThresholdS** is a standalone subsystem within **CGRateS** responsible to execute a list of *Actions* for a specific event received to process. It is accessed via `CGRateS RPC APIs <https://godoc.org/github.com/cgrates/cgrates/apier/>`_.
+**ThresholdS** is a standalone subsystem within **CGRateS** responsible to execute a list of *Actions* for a specific event received to process. It is accessed via `CGRateS RPC APIs <https://pkg.go.dev/github.com/cgrates/cgrates/apier@master/>`_.
 
 As most of the other subsystems, it is performance oriented, stored inside *DataDB* but cached inside the *cgr-engine* process. 
 Caching can be done dynamically/on-demand or at start-time/precached and it is configurable within *cache* section in the :ref:`JSON configuration <configuration>`.